int64 versions were switched to volatile pointers in cl1.1
cl1.1 also renamed atom_ functions to atomic_ that use volatile pointers.
CTS and applications use volatile pointers.
Passes CTS on carrizo
no return piglit tests still pass on turks.
Reviewed-By: Aaron Watry <awatry@gmail.com>
Tested-By: Aaron Watry <awatry@gmail.com>
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 335280
These are just atomic_* wrappers.
Switch inc, dec to use atomic_* wrappers as well.
Reviewed-By: Aaron Watry <awatry@gmail.com>
Tested-By: Aaron Watry <awatry@gmail.com>
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 335279
It's easier to just list the four function declarations
Reviewed-By: Aaron Watry <awatry@gmail.com>
Tested-By: Aaron Watry <awatry@gmail.com>
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 335275
This reverts commit r335206.
As discussed here: https://reviews.llvm.org/rL333740, a fix will come
tomorrow. In the meanwhile, revert this to fix some bots.
llvm-svn: 335272
BlockWaitcntProcessedSet was not being cleared between calls, so it was
producing incorrect counts in cases where MBB addresses happened to coincide
across multiple calls.
Differential Revision: https://reviews.llvm.org/D48391
llvm-svn: 335268
and everything that comes with it from implementation
and v3 header files.
Leave definition in v2 header files for backwards
compatibility.
Differential Revision: https://reviews.llvm.org/D48191
llvm-svn: 335267
Summary:
The logic for handling the sinking of COPY instructions was generating
different code when building with debug flags.
The original code did not take into consideration debug instructions. This
resulted in the registers in the DBG_VALUE instructions being treated as used,
and prevented the COPY from being sunk. This patch avoids analyzing debug
instructions when trying to sink COPY instructions.
This patch also creates a routine from the code in MachineSinking::SinkInstruction to
perform the logic of sinking an instruction along with its debug instructions.
This functionality is used in multiple places, including the code for sinking COPY instrs.
Reviewers: junbuml, javed.absar, MatzeB, bjope
Reviewed By: bjope
Subscribers: aprantl, probinson, thegameg, jonpa, bjope, vsk, kristof.beyls, JDevlieghere, llvm-commits
Tags: #debug-info
Differential Revision: https://reviews.llvm.org/D45637
llvm-svn: 335264
The previous code worked with vectors, but it failed when the
vector constants contained undef elements.
The matchers handle those cases.
llvm-svn: 335262
Jim pointed out that XCode has build configurations that build without
python and removing the ifdefs around the python code breaks them.
This reverts the #ifdef part of the above patch, while keeping the cmake
parts.
llvm-svn: 335260
ud2 and int2c were missing declarations entirely. And the bitscans were only under x86_64, but they seem to be in BuiltinsARM.def as well and are tested by ms_intrinsics.c
Differential Revision: https://reviews.llvm.org/D48187
llvm-svn: 335259
This is outwardly NFC from what I can tell, but it should be more efficient
to simplify first (despite the name, SimplifyAssociativeOrCommutative does
not actually simplify as InstSimplify does - it creates/morphs instructions).
This should make it easier to refactor duplicated code that runs for all binops.
llvm-svn: 335258
The new IR fixes a mismatch in the final extractelement for the i32 intrinsics. Previously we extracted a 64-bit element even though we only wanted 32 bits.
SimplifyDemandedElts isn't able to make FP elements undef now and the shuffle mask I used prevents the use of horizontal add we had before. Not sure we should have been using horizontal add anyway. It's implemented on Intel with two port 5 shuffles and an add. So we have on less shuffle now, but an additional instruction to decode.
Differential Revision: https://reviews.llvm.org/D48347
llvm-svn: 335256
Summary:
This test is a strip down version of a function inside the
amalgamated sqlite source. When converted to IR clang produces
a phi instruction without debug location.
This patch fixes the above issue.
Differential Revision: https://reviews.llvm.org/D47720
llvm-svn: 335255
Similar to what was done to max/min recently.
These already reduced the vector width to 256 and 128 bit as we go unlike the original max/min code.
Differential Revision: https://reviews.llvm.org/D48346
llvm-svn: 335253
I don't remember why I added it, but it's definitely not needed, since the check
doesn't have any options and the check doesn't have any special relation to the
Google C++ style.
llvm-svn: 335252
This reverts commit d8f57105010cc7e78026e511d5def873fc91e0e7.
Original Commit:
Author: Haicheng Wu <haicheng@codeaurora.org>
Date: Sun Feb 18 13:51:33 2018 +0000
[AArch64] Coalesce Copy Zero during instruction selection
Add special case for copy of zero to avoid a double copy.
Differential Revision: https://reviews.llvm.org/D36104
Author's intention is to remove a BB that has one mov instruction. In
order to do that, d8f571050 pessmizes MachineSinking by introducing a
copy, such that mov instruction is NOT moved to the BB. Optimization
downstream gets rid of the BB with only mov instruction. This works well
if we have only one fall through branch as there is only one "extra"
mov instruction.
If we have multiple fall throughs, we will have a lot of redundant movs.
In such a case, it's better to have this BB which has one mov instruction.
This is causing degradation in jpeg, fft and other codebases. I believe
if we want to remove a BB with only one branch instruction, we should not
pessimize Machine Sinking at all, and find some other solution.
llvm-svn: 335251
Allowed folding for "and/or" binops with non-constant operand if
arguments of select are 0/-1 values.
Normally this code with "and" opcode does not get to a DAG combiner
and simplified yet in the InstCombine. However AMDGPU produces it
during lowering and InstCombine has no chance to optimize it out.
In turn the same pattern with "or" opcode can reach DAG.
Differential Revision: https://reviews.llvm.org/D48301
llvm-svn: 335250
This option allows codegen (such as DAGCombine or MI scheduling) to use alias
analysis information, which can help with the codegen on in-order cpu's,
especially machine scheduling. Here I have done things the same way as AArch64,
adding a subtarget feature to enable this for specific cores, and enabled it for
the R52 where we have a schedule to make use of it.
Differential Revision: https://reviews.llvm.org/D48074
llvm-svn: 335249
I've made the code accept only 16 byte UUIDs, which is technically not
NFC (previously it would also accept 20 byte ones, but use only the
first 16 bytes), but this should be more correct as mac UUIDs are always
16 byte long.
llvm-svn: 335247
Instead of a separate GetBytes + GetByteSize methods I introduce a
single GetBytes method returning an ArrayRef.
This is NFC cleanup now, but it should make handling arbitrarily-sized
UUIDs cleaner, should we choose to go that way. I also took the
opportunity to add some unit tests for this class.
llvm-svn: 335244
Summary:
When expanding the PseudoTail in expandFunctionCall() we were using X6
to save the return address. Since this is a tail call the return
address is not needed, this patch replaces it with X0 to be ignored.
This matches the behaviour listed in the ISA V2.2 document page 110.
tail offset -----> jalr x0, x6, offset
GCC exhibits the same behavior.
Reviewers: apazos, asb, mgrang
Reviewed By: asb
Subscribers: rbar, johnrusso, simoncook, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01
Differential Revision: https://reviews.llvm.org/D48343
llvm-svn: 335239
This should help in lowering the following four intrinsics:
_mm256_cvtepi32_epi8
_mm256_cvtepi64_epi16
_mm256_cvtepi64_epi8
_mm512_cvtepi64_epi8
Differential Revision: https://reviews.llvm.org/D46957
llvm-svn: 335238
Summary: Pretty much everything we need is in llvm::TargetMachine.
Reviewers: gchatelet
Subscribers: llvm-commits, tschuett
Differential Revision: https://reviews.llvm.org/D48428
llvm-svn: 335237
Instead of #ifdef-ing the contents of all files in the plugin for all
non-python builds, just disable the plugin at the cmake level. Also,
remove spurious extra linking of the Python plugin in liblldb. This
plugin is already included as a part of LLDB_ALL_PLUGINS variable.
llvm-svn: 335236
These tests are extremely environment-dependent. if the environment is
not module-enabled (which is the likely scenario), they won't test
anything. If one happens to have a module-enabled libc++, then the he
will start running into problems.
The first one is that the debug info in pcm file contains relocations
that ObjectFileELF doesn't handle (particularly on non-x86
architectures), but even after that is resolved, it seems we still are
unable to pull debug info out of the pcm file. I've filed pr37893 to
track that, and I am disabling gmodules tests on linux until these
issues are resolved.
llvm-svn: 335235
Undefined first referenced
symbol in file
clang_getCompletionFixIt /var/gcc/llvm/obj/local/tools/clang/tools/libclang/libclang.exports
clang_getTokenLocation /var/gcc/llvm/obj/local/tools/clang/tools/libclang/libclang.exports
clang_getToken /var/gcc/llvm/obj/local/tools/clang/tools/libclang/libclang.exports
clang_getTemplateCursorKind /var/gcc/llvm/obj/local/tools/clang/tools/libclang/libclang.exports
clang_getTUResourceUsageName /var/gcc/llvm/obj/local/tools/clang/tools/libclang/libclang.exports
clang_getCompletionChunkKind /var/gcc/llvm/obj/local/tools/clang/tools/libclang/libclang.exports
clang_getCompletionChunkText /var/gcc/llvm/obj/local/tools/clang/tools/libclang/libclang.exports
clang_getSpellingLocation /var/gcc/llvm/obj/local/tools/clang/tools/libclang/libclang.exports
clang_getCompletionParent /var/gcc/llvm/obj/local/tools/clang/tools/libclang/libclang.exports
clang_getCompletionChunkCompletionString /var/gcc/llvm/obj/local/tools/clang/tools/libclang/libclang.exports
clang_getCompletionPriority /var/gcc/llvm/obj/local/tools/clang/tools/libclang/libclang.exports
clang_getCompletionNumFixIts /var/gcc/llvm/obj/local/tools/clang/tools/libclang/libclang.exports
clang_getTokenExtent /var/gcc/llvm/obj/local/tools/clang/tools/libclang/libclang.exports
clang_getCompletionNumAnnotations /var/gcc/llvm/obj/local/tools/clang/tools/libclang/libclang.exports
clang_getTokenKind /var/gcc/llvm/obj/local/tools/clang/tools/libclang/libclang.exports
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
make[2]: *** [tools/clang/tools/libclang/CMakeFiles/libclang.dir/build.make:651: lib/libclang.so.7] Error 1
It turns out that this is caused by https://reviews.llvm.org/D46862: it added a
couple of CRs (^M) to some lines. Solaris ld takes them to be part of the symbol
names, which of course are missing from the input objects. GNU ld handles this
just fine. Fixed by removing the CRs.
Bootstrapped on i386-pc-solaris2.11. I guess this is obvious.
Differential Revision: https://reviews.llvm.org/D48423
llvm-svn: 335234
Summary:
For sample and gather ops, we can accurately determine the set of
vaddr-size instruction variants that are required. This reduces
the size of instruction tables by ~5%.
The number of machine instruction opcodes is reduced from 10002
to 9476.
Change-Id: Ie7fc65d3657b762c7816017fe70b2e9bec644a8a
Reviewers: arsenm, rampitec
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D48168
llvm-svn: 335232
Summary:
This also removes the need for atomic pseudo instructions, since
we select the correct encoding directly in SITargetLowering::lowerImage
for dimension-aware image intrinsics.
Mesa uses dimension-aware image intrinsics since
commit a9a7993441.
Change-Id: I7473d20009476a4ed6d919cae4e6dca9ff42e77a
Reviewers: arsenm, rampitec, mareko, tpr, b-sumner
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D48167
llvm-svn: 335231
Summary:
Use the expanded features of the TableGen generic tables to avoid manually
adding the combinatorially exploded set of intrinsics. The
getAMDGPUImageDimIntrinsic lookup function is early-out,
i.e. non-AMDGPU intrinsics will never look at the underlying table.
Use a generic approach for getting the new intrinsic overload to keep the
code simple, and make the image dmask handling more generic:
- handle non-sampler image loads
- handle the case where the set of demanded elements is not a prefix
There is some overlap between this code and an optimization that happens
in the backend during code generation. They currently complement each other:
- only the codegen optimization can generate vec3 loads
- only the InstCombine optimization can handle D16
The InstCombine optimization also likely covers more cases since the
codegen optimization is fairly ad-hoc. Ideally, we'll remove the optimization
in codegen once the infrastructure for vec3 is in place (which will probably
take a long time).
Modify the test cases to use dimension-aware intrinsics. This makes it
easier to see that the test coverage for the new intrinsics is equivalent,
and the old style intrinsics will be removed in a follow-up commit anyway.
Change-Id: I4b91ea661413d13004956fe4ef7d13d41b8ce3ad
Reviewers: arsenm, rampitec, majnemer
Subscribers: kzhuravl, wdng, mgorny, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D48165
llvm-svn: 335230
Jan Vesely