| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added support of the following opcodes:
v_pk_sub_u16
v_pk_mad_i16
v_pk_mad_u16
See Bug 33593: https://bugs.llvm.org//show_bug.cgi?id=33593
Reviewers: vpykhtin, artem.tamazov, arsenm
Differential Revision: https://reviews.llvm.org/D34890
llvm-svn: 308281
|
| |
|
|
|
|
|
|
| |
This enables the suggestions of other mnemonics when invalid ones are
specified.
Review: Ulrich Weigand
llvm-svn: 308280
|
| |
|
|
|
|
|
|
| |
Treat widening G_SREM and G_UREM the same as G_SDIV and G_UDIV. This is
going to be used in the ARM backend (and that's when the test will come
too).
llvm-svn: 308278
|
| |
|
|
|
|
| |
removed in r308212. [-Wdocumentation]
llvm-svn: 308276
|
| |
|
|
| |
llvm-svn: 308275
|
| |
|
|
|
|
|
|
|
|
| |
The commit r308100 updated WebAssembly tests for r308025. In one case it
merely made the test more resilient but in another case it made
a substantive update. Because r308025 was reverted in r308271, these
changes to the test also need to be reverted. They should be folded into
the recommit of r308025 when it is ready.
llvm-svn: 308273
|
| |
|
|
|
|
|
| |
Notably, this is failing on our PPC build bots:
http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/8338/steps/ninja%20check%201/logs/FAIL%3A%20LLVM%3A%3Apr33772.ll
llvm-svn: 308272
|
| |
|
|
|
|
|
|
|
| |
with a minimal test case in http://llvm.org/PR33833.
Original commit message:
Improve Aliasing of operations to static alloca
llvm-svn: 308271
|
| |
|
|
|
|
|
| |
Original commit log:
[AMDGPU] CodeGen: check dst operand type to determine if omod is supported for VOP3 instructions
llvm-svn: 308270
|
| |
|
|
|
|
|
|
|
|
| |
non-constant scale value.
This isn't legal code, but we shouldn't crash on it. Now we just don't convert the gather intrinsic if the scale isn't constant and let it go through to isel where we'll report an isel failure.
Fixes PR33772.
llvm-svn: 308267
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
optimizeMemoryInst contains a vector AddrModeInsts.
The only use of this vector is to check that all instructions are in the same
block as memory instruction. This check is guarded by PhiSeen flag,
so if we traversed through phi node then we do not need to keep information
in AddrModeInsts. AddModeInsts is set first time we found some addressing mode
and updated if we found new one later.
We can find next addressing mode only if we traverse phi node so all code
related to update of AddModeInsts can be safely removed.
Reviewers: loladiro, spatel, efriedma
Reviewed By: efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35291
llvm-svn: 308265
|
| |
|
|
|
|
|
|
|
|
| |
In some particular cases eq/ne conditions can be turned into equivalent
slt/sgt conditions. This patch teaches parseLoopStructure to handle some
of these cases.
Differential Revision: https://reviews.llvm.org/D35010
llvm-svn: 308264
|
| |
|
|
|
|
| |
This reverts commit 223ef99f839f6b056272bcf4390841fcb26dda3c.
llvm-svn: 308263
|
| |
|
|
|
|
| |
This reverts commit f3aaaac609f801df6c12655ec203455be7094627.
llvm-svn: 308262
|
| |
|
|
|
|
| |
This reverts commit 66093fd60b848572f676023b8387bff69b151511.
llvm-svn: 308261
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
other Statistic variables
Summary:
Previously, we counted TotalMemInst by reading certain instruction counters before and after calling visit and then finding the difference. But that wouldn't be thread safe if this same pass was being ran on multiple threads.
This list of "memory instructions" doesn't make sense to me as it includes call/invoke and is missing atomics.
This patch removes the counter all together.
Reviewers: hfinkel, chandlerc, davide
Reviewed By: davide
Subscribers: davide, llvm-commits
Differential Revision: https://reviews.llvm.org/D33608
llvm-svn: 308260
|
| |
|
|
|
|
| |
Some shells seem to have trouble parsing non-alphanumeric symbols.
llvm-svn: 308259
|
| |
|
|
|
|
| |
of very input (seems to work much better)
llvm-svn: 308253
|
| |
|
|
| |
llvm-svn: 308252
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add canary tests to verify that MSAN currently does nothing with the element atomic memory intrinsics for memcpy, memmove, and memset.
Placeholder tests that will fail once element atomic @llvm.mem[cpy|move|set] instrinsics have been added to the MemIntrinsic class hierarchy. These will act as a reminder to verify that MSAN handles these intrinsics properly once they have been added to that class hierarchy.
Reviewers: reames
Reviewed By: reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35510
llvm-svn: 308251
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add canary tests to verify that ESAN currently does nothing with the element atomic memory intrinsics for memcpy, memmove, and memset.
Placeholder tests that will fail once element atomic @llvm.mem[cpy|move|set] instrinsics have been added to the MemIntrinsic class hierarchy. These will act as a reminder to verify that ESAN handles these intrinsics properly once they have been added to that class hierarchy.
Reviewers: reames
Reviewed By: reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35508
llvm-svn: 308250
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add canary tests to verify that DFSAN currently does nothing with the element atomic memory intrinsics for memcpy, memmove, and memset.
Placeholder tests that will fail once @llvm.mem[cpy|move|set] instrinsics have been added to the MemIntrinsic class hierarchy. These will act as a reminder to verify that DFSAN handles these intrinsics properly once they have been added to that class hierarchy.
Note that there could be some trickiness with these element-atomic intrinsics for the dataflow sanitizer in racy multithreaded programs. The data flow sanitizer inserts additional lib calls to mirror the memory intrinsic's action, so it is possible (very likely, even) that the dfsan buffers will not be in sync with the original buffers. Furthermore, implementation of the dfsan buffer updates for the element atomic intrinsics will have to also use unordered atomic instructions. If we can assume that dfsan is never run on racy multithreaded programs, then the element atomic memory intrinsics can pretty much be treated the same as the regular memory intrinsics.
Reviewers: reames
Reviewed By: reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35507
llvm-svn: 308249
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add canary tests to verify that ASAN currently does nothing with the element atomic memory intrinsics for memcpy, memmove, and memset.
Placeholder tests that will fail once element atomic @llvm.mem[cpy|move|set] instrinsics have been added to the MemIntrinsic class hierarchy. These will act as a reminder to verify that ASAN handles these intrinsics properly once they have been added to that class hierarchy.
Reviewers: reames
Reviewed By: reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35505
llvm-svn: 308248
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add canary tests to verify that InstCombine currently does nothing with the element atomic memory intrinsics for memmove and memset.
Placeholder tests that will fail once element atomic @llvm.mem[move|set] instrinsics have been added to the MemIntrinsic class hierarchy. These will act as a reminder to verify that inst combine handles these intrinsics properly once they have been added to that class hierarchy.
Reviewers: reames
Reviewed By: reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D35502
llvm-svn: 308247
|
| |
|
|
| |
llvm-svn: 308246
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch modifies the handleDebugInfo() function so that we verify the contents of each unit
in the .debug_info section only if its header has been successfully verified.
This change will allow for more/different verification checks depending on the type of the unit since from
dwarf5, the .debug_info section may consist of different types of units.
Subscribers: aprantl
Differential Revision: https://reviews.llvm.org/D35521
llvm-svn: 308245
|
| |
|
|
| |
llvm-svn: 308244
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This removes the CVTypeVisitor updater and verifier classes. They were
made dead by the minimal type dumping refactoring. Replace them with a
single function that takes a type record and produces a hash. Call this
from the minimal type dumper and compare the hash.
I also noticed that the microsoft-pdb reference repository uses a basic
CRC32 for records that aren't special. We already have an implementation
of that CRC ready to use, because it's used in COFF for ICF.
I'll make LLD call this hashing utility in a follow-up change. We might
also consider using this same hash in type stream merging, so that we
don't have to hash our records twice.
Reviewers: inglorion, ruiu
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D35515
llvm-svn: 308240
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Object files compiled with /Zi emit type information into a type server
PDB. The .debug$S section will contain a single TypeServer2Record with
the absolute path and GUID of the type server. LLD needs to load the
type server PDB and merge all types and items it finds in it into the
destination PDB.
Depends on D35495
Reviewers: ruiu, inglorion
Subscribers: zturner, llvm-commits
Differential Revision: https://reviews.llvm.org/D35504
llvm-svn: 308235
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We were treating the GUIDs in TypeServer2Record as strings, and the
non-ASCII bytes in the GUID would not round-trip through YAML.
We already had the PDB_UniqueId type portably represent a Windows GUID,
but we need to hoist that up to the DebugInfo/CodeView library so that
we can use it in the TypeServer2Record as well as in PDB parsing code.
Reviewers: inglorion, amccarth
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D35495
llvm-svn: 308234
|
| |
|
|
| |
llvm-svn: 308232
|
| |
|
|
| |
llvm-svn: 308227
|
| |
|
|
|
|
|
|
| |
This wasn't necessary before since they are always enabled
for kernels, but this is necessary if they need to be
forwarded to a callable function.
llvm-svn: 308226
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the first patch towards creating the llvm-mt tool for merging
Windows manifests. This is a reimplementation of mt.exe.
Reviewers: zturner, ruiu, rnk
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D35333
llvm-svn: 308224
|
| |
|
|
| |
llvm-svn: 308223
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This didn't do much to speed things up, but it implements a FIXME, and I
think it's a nice simplification. We don't need the record kind switch.
We're doing that ourselves.
Reviewers: ruiu, inglorion
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D35496
llvm-svn: 308213
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Instead of wiring these through the CVTypeVisitor interface, clients
should inspect the CVTypeArray before visiting it and potentially load
up the type server's TPI stream if they need it.
No tests relied on this functionality because LLD was the only client.
Reviewers: ruiu
Subscribers: mgorny, hiraditya, zturner, llvm-commits
Differential Revision: https://reviews.llvm.org/D35394
llvm-svn: 308212
|
| |
|
|
| |
llvm-svn: 308211
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Rename the enum value from X86_64_Win64 to plain Win64.
The symbol exposed in the textual IR is changed from 'x86_64_win64cc'
to 'win64cc', but the numeric value is kept, keeping support for
old bitcode.
Differential Revision: https://reviews.llvm.org/D34474
llvm-svn: 308208
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function copy to import""
This reverts commit r308114 (and follow on fixes to test).
There is a linking failure in a ThinLTO bot:
http://green.lab.llvm.org/green/job/clang-stage2-configure-Rthinlto_build/3663/
(and undefined reference). It seems like it must be a second order
effect of the heuristic change I made, and may take some time to try
to reproduce locally and track down. Therefore, reverting for now.
llvm-svn: 308206
|
| |
|
|
|
|
| |
As suggested by Dave Blaikie in review on r307952. Thanks Dave!
llvm-svn: 308203
|
| |
|
|
|
|
|
|
| |
This reverts commit 546e006a023cccd0fd32afd442ab992d3515d4b8.
Reverting until I can figure out llvm-symbolizer breakages on mac os.
llvm-svn: 308202
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This allows to pass the build directory where all the opt.yaml files are
rather than find | xargs which may invoke opt-viewer multiple times producing
incomplete html output.
The patch generalizes the same functionality from opt-diff.
Differential Revision: https://reviews.llvm.org/D35491
llvm-svn: 308200
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the new 128-bit vector float instructions of z14.
Note that these instructions actually only operate on the f128 type,
since only each 128-bit vector register can hold only one 128-bit
float value. However, this is still preferable to the legacy 128-bit
float instructions, since those operate on pairs of floating-point
registers (so we can hold at most 8 values in registers), while the
new instructions use single vector registers (so we hold up to 32
value in registers).
Adding support includes:
- Enabling the instructions for the assembler/disassembler.
- CodeGen for the instructions. This includes allocating the f128
type now to the VR128BitRegClass instead of FP128BitRegClass.
- Scheduler description support for the instructions.
Note that for a small number of operations, we have no new vector
instructions (like integer <-> 128-bit float conversions), and so
we use the legacy instruction and then reformat the operand
(i.e. copy between a pair of floating-point registers and a
vector register).
llvm-svn: 308196
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the new 32-bit vector float instructions of z14.
This includes:
- Enabling the instructions for the assembler/disassembler.
- CodeGen for the instructions, including new LLVM intrinsics.
- Scheduler description support for the instructions.
- Update to the vector cost function calculations.
In general, CodeGen support for the new v4f32 instructions closely
matches support for the existing v2f64 instructions.
llvm-svn: 308195
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch series adds support for the IBM z14 processor. This part includes:
- Basic support for the new processor and its features.
- Support for new instructions (except vector 32-bit float and 128-bit float).
- CodeGen for new instructions, including new LLVM intrinsics.
- Scheduler description for the new processor.
- Detection of z14 as host processor.
Support for the new 32-bit vector float and 128-bit vector float
instructions is provided by separate patches.
llvm-svn: 308194
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: t.p.northover, oren_ben_simhon, niravd, mcrosier
Reviewed By: oren_ben_simhon, mcrosier
Subscribers: nhaehnle, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D35466
llvm-svn: 308193
|
| |
|
|
|
|
|
| |
The target-independent lowering works fine, except concatenating 32-bit
words. Add a pattern to generate A2_combinew instead of 64-bit asl/or.
llvm-svn: 308186
|
| |
|
|
|
|
|
|
|
| |
Prevent store merge from merging stores into an invalid 128-bit store
(realized as a f128 value in the context of the noimplicitfloat
attribute). Previously, such stores are immediately split back into
valid stores.
llvm-svn: 308184
|
| |
|
|
| |
llvm-svn: 308180
|