Summary:
Fix a compiler bug when the lane select happens to end up in a VGPR.
Clarify the semantic of the corresponding intrinsic to be that of
the corresponding GLSL: the lane select must be uniform across a
wave front, otherwise results are undefined.
Reviewers: arsenm
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D32343
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301197 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Instead of keeping a variable indicating whether there are early exits
in the loop. We keep all the early exits. This improves LICM's ability to
move instructions out of the loop based on is-guaranteed-to-execute.
I am going to update compilation time as well soon.
Reviewers: hfinkel, sanjoy, efriedma, mkuper
Reviewed By: hfinkel
Subscribers: llvm-commits, mzolotukhin
Differential Revision: https://reviews.llvm.org/D32433
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301196 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The return value of these intrinsics should always have 0 bits for
inactive threads. This means that when all arguments are constant
and the comparison evaluates to true, the intrinsic should return
the current exec mask.
Fixes some GL_ARB_shader_ballot tests.
Reviewers: arsenm
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D32344
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301195 91177308-0d34-0410-b5e6-96231b3b80d8
As discussed on D32039, use MaskByteOffset to describe the variable and also pull out repeated getOpcode() calls.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301193 91177308-0d34-0410-b5e6-96231b3b80d8
While we use BaseIndexOffset in FindBetterNeighborChains to
appropriately realize they're almost the same address and should be
improved concurrently we do not use it in isAlias using the non-index
understanding FindBaseOffset instead. Adding a BaseIndexOffset check
in isAlias like should allow indexed stores to be merged.
FindBaseOffset to be excised in subsequent patch.
Reviewers: jyknight, aditya_nandakumar, bogner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31987
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301187 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Region objects capture the address of the creating RegionInfo instance. Because the RegionInfo class is movable, moving a RegionInfo object creates dangling references. This patch fixes these references by walking the Regions post-move, and updating references to the new parent.
Reviewers: Meinersbur, grosser
Reviewed By: Meinersbur, grosser
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31719
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301175 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: SUSE's ARM triples end with -gnueabi even though they are hard-float. This requires special handling of SUSE ARM triples. Hence we need a way to differentiate the SUSE as vendor. This CL adds that.
Reviewers: chandlerc, compnerd, echristo, rengolin
Reviewed By: rengolin
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D32426
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301174 91177308-0d34-0410-b5e6-96231b3b80d8
I found this when investigated "Bug 32319 - .gdb_index is broken/incomplete" for LLD.
When we have object file with .debug_ranges section it may be filled with zeroes.
Relocations are exist in file to relocate this zeroes into real values later, but until that
a pair of zeroes is treated as terminator. And DWARF parser thinks there is no ranges at all
when I am trying to collect address ranges for building .gdb_index.
Solution implemented in this patch is to take relocations in account when parsing ranges.
Differential revision: https://reviews.llvm.org/D32228
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301170 91177308-0d34-0410-b5e6-96231b3b80d8
We have to widen the operands to 32 bits and then we can either use
hardware division if it is available or lower to a libcall otherwise.
At the moment it is not enough to set the Legalizer action to
WidenScalar, since for libcalls it won't know what to do (it won't be
able to find what size to widen to, because it will find Libcall and not
Legal for 32 bits). To hack around this limitation, we request Custom
lowering, and as part of that we widen first and then we run another
legalizeInstrStep on the widened DIV.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301166 91177308-0d34-0410-b5e6-96231b3b80d8
Instruction isb takes as an operand either 'sy' or an immediate value. This
improves the diagnostic when the string is not 'sy' and adds a test case for
this which was missing. This also adds tests to check invalid inputs for dsb
and dmb.
Differential Revision: https://reviews.llvm.org/D32227
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301165 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for both targets with hardware division and without. For
hardware division we have to add support throughout the pipeline
(legalizer, reg bank select, instruction select). For targets without
hardware division, we only need to mark it as a libcall.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301164 91177308-0d34-0410-b5e6-96231b3b80d8
Treat them the same as the other binary operations that we have so far,
but on integers rather than floating point types. Extract the common
code into a helper.
This will be used in the ARM backend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301163 91177308-0d34-0410-b5e6-96231b3b80d8
When selecting a G_CONSTANT to a MOVi, we need the value to be an Imm
operand. We used to just leave the G_CONSTANT operand unchanged, which
works in some cases (such as the GEP offsets that we create when
referring to stack slots). However, in many other places the G_CONSTANTs
are created with CImm operands. This patch makes sure to handle those as
well, and to error out gracefully if in the end we don't end up with an
Imm operand.
Thanks to Oliver Stannard for reporting this issue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301162 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is a tool for comparing the function graphs produced by the
llvm-xray graph too. It takes the form of a new subcommand of the
llvm-xray tool 'graph-diff'.
This initial version of the patch is very rough, but it is close to
feature complete.
Depends on D29363
Reviewers: dblaikie, dberris
Reviewed By: dberris
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29320
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301160 91177308-0d34-0410-b5e6-96231b3b80d8
Previously single word would always return 0 regardless of the original sign. Multi word would return all 0s or all 1s based on the original sign. Now single word takes into account the sign as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301159 91177308-0d34-0410-b5e6-96231b3b80d8
The changes are causing the i686-mingw32 build to fail.
This reverts commit r301153, and the changes for a separate warning on i686-mingw32 in r301155 and r301156.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301157 91177308-0d34-0410-b5e6-96231b3b80d8
libraries are properly unloaded when llvm_shutdown is called.
Summary:
This was mostly affecting usage of the JIT, where storing the library handles in
a set made iteration unordered/undefined. This lead to disagreement between the
JIT and native code as to what the address and implementation of particularly on
Windows with stdlib functions:
JIT: putenv_s("TEST", "VALUE") // called msvcrt.dll, putenv_s
JIT: getenv("TEST") -> "VALUE" // called msvcrt.dll, getenv
Native: getenv("TEST") -> NULL // called ucrt.dll, getenv
Also fixed is the issue of DynamicLibrary::getPermanentLibrary(0,0) on Windows
not giving priority to the process' symbols as it did on Unix.
Reviewers: chapuni, v.g.vassilev, lhames
Reviewed By: lhames
Subscribers: danalbert, srhines, mgorny, vsk, llvm-commits
Differential Revision: https://reviews.llvm.org/D30107
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301153 91177308-0d34-0410-b5e6-96231b3b80d8
There are more bugs (runtime failures) triggered when partial
inlining is turned on. Add options to help triaging problems.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301148 91177308-0d34-0410-b5e6-96231b3b80d8
This change reboots SCEV's current (off by default) verification logic
to avoid false failures. Instead of stringifying trip counts, it maps
old and new trip counts to the same ScalarEvolution "universe" and
asks ScalarEvolution to compute the difference between them. If the
difference comes out to be a non-zero constant, then (barring some
corner cases) we *know* we messed up.
I've not yet enabled this by default since it hits an exponential time
issue in SCEV, but once I fix that, I'll flip it on by default in
EXPENSIVE_CHECKS builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301146 91177308-0d34-0410-b5e6-96231b3b80d8
We handled all of the commuted variants for plain xor already,
although they were scattered around and sometimes folded less
efficiently using distributive laws. We had no folds for not-xor.
Handling all of these patterns consistently is part of trying to
reinstate:
https://reviews.llvm.org/rL300977
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301144 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In case all predecessor go to a single successor of current BB. We want to fold (not thread).
I failed to update the phi nodes properly in the last patch https://reviews.llvm.org/rL300657.
Phi nodes values are per predecessor in LLVM.
Reviewers: sanjoy
Reviewed By: sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32400
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301139 91177308-0d34-0410-b5e6-96231b3b80d8
This makes the WordBits calculation calculate a value between 1 and 64 for the number of bits in the last word. Previously if the BitWidth was a multiple of 64 bits the WordBits value was 0 and we had to bail out early to avoid an undefined shift. Now with a value of 64 we no longer have an undefined shift issue.
This shows a 15-16k reduction in the size of the opt binary on my local x86-64 build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301134 91177308-0d34-0410-b5e6-96231b3b80d8
The current code is trying to be clever with shifts to avoid needing to clear unused bits. But it looks like the compiler is unable to optimize out the unused bit handling in the APInt constructor. Given this its better to just use SignExtend64 and have more readable code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301133 91177308-0d34-0410-b5e6-96231b3b80d8
There's probably some better way to write this that eliminates the
code duplication without hurting readability, but at least this
eliminates the logic holes and is hopefully slightly more efficient
than creating new instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301129 91177308-0d34-0410-b5e6-96231b3b80d8
