This is a pre-commit for a patch I'm working on to turn KnownZero/One into a struct. Once I do that the type here will be less obvious.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301324 91177308-0d34-0410-b5e6-96231b3b80d8
This is a pre-commit for a patch that I'm working on to merge KnownZero/KnownOne into a KnownBits struct which would have had to touch this line.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301323 91177308-0d34-0410-b5e6-96231b3b80d8
This patch reapplies r301309 with the fix to the MIR test to fix the assertion
triggered by r301309. Had trimmed a little bit too much from the MIR!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301317 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes a bug with the updating of DBG_VALUE's in
BreakAntiDependencies. Previously, it would only attempt to update the first
DBG_VALUE following the instruction whose register is being changed,
potentially leaving DBG_VALUE's referring to the wrong register. Now the code
will update all DBG_VALUE's that immediately follow the instruction.
This issue was detected as a result of an optimized codegen difference with
"-g" where an X86 byte/word fixup was not performed due to a DBG_VALUE
referencing the wrong register.
Differential Revision: https://reviews.llvm.org/D31755
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301309 91177308-0d34-0410-b5e6-96231b3b80d8
One of the fast-math optimizations is to replace calls to standard double
functions with their float equivalents, e.g. exp -> expf. However, this can
cause infinite loops for the following:
float expf(float val) { return (float) exp((double) val); }
A similar inline declaration exists in the MinGW-w64 math.h header file which
when compiled with -O2/3 and fast-math generates infinite loops.
So this fix checks that the calling function to the standard double function
that is being replaced does not match the float equivalent.
Differential Revision: https://reviews.llvm.org/D31806
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301304 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In a previous change I changed SCEV's normalization / denormalization
to work with non-affine add recs. So the bailout in IVUsers can be
removed.
Reviewers: atrick, efriedma
Reviewed By: atrick
Subscribers: davide, mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D32105
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301298 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is part of D28975's breakdown.
Genreating the control-flow to guard predicated instructions modified to
only use SplitBlockAndInsertIfThen() for producing the if-then construct.
Differential Revision: https://reviews.llvm.org/D32224
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301293 91177308-0d34-0410-b5e6-96231b3b80d8
We need to do this to prevent a miscompile which sinks an objc_retain
past an objc_release that releases the object objc_retain retains. This
happens because the top-down and bottom-up traversals each determines
the insert point for retain or release individually without knowing
where the other instruction is moved.
For example, when the following IR is fed to the ARC optimizer, the
top-down traversal decides to insert objc_retain right before
objc_release and the bottom-up traversal decides to insert objc_release
right after clang.arc.use.
(IR before ARC optimizer)
%11 = call i8* @objc_retain(i8* %10)
call void (...) @clang.arc.use(%0* %5)
call void @llvm.dbg.value(...)
call void @objc_release(i8* %6)
This reverses the order of objc_release and objc_retain, which causes
the object to be destructed prematurely.
(IR after ARC optimizer)
call void (...) @clang.arc.use(%0* %5)
call void @objc_release(i8* %6)
call void @llvm.dbg.value(...)
%11 = call i8* @objc_retain(i8* %10)
rdar://problem/30530580
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301289 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Before this change, SCEV Normalization would incorrectly normalize
non-affine add recurrences. To work around this there was (still is)
a check in place to make sure we only tried to normalize affine add
recurrences.
We recently found a bug in aforementioned check to bail out of
normalizing non-affine add recurrences. However, instead of fixing
the bailout, I have decided to teach SCEV normalization to work
correctly with non-affine add recurrences, making the bailout
unnecessary (I'll remove it in a subsequent change).
I've also added some unit tests (which would have failed before this
change).
Reviewers: atrick, sunfish, efriedma
Reviewed By: atrick
Subscribers: mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D32104
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301281 91177308-0d34-0410-b5e6-96231b3b80d8
This is just asserting all the operations are handled in the
switch, which the unreachable already handles.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301270 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the temporary, poorly named getSlotSet method which did the same
thing. Also remove getSlotNode, which is a hold-over from when we were
dealing with AttributeSetNode* instead of AttributeSet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301267 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
`git apply` on Windows doesn't work for files that SVN checks out as
CRLF. There is no way to force SVN to check everything out with Unix
line endings on Windows. Files with svn:eol-style=native will always
come out with CRLF, breaking `git apply`, which wants Unix line endings.
My workaround is to list all files with this property set in the change,
and run `dos2unix` on them. SVN doesn't commit a massive line ending
change because the svn:eol-style property indicates that these are text
files.
Tested on r301245.
Reviewers: zturner, jlebar
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32452
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301262 91177308-0d34-0410-b5e6-96231b3b80d8
We can simplify (and (icmp X, C1), (icmp X, C2)) to one of the icmps in many cases.
I had to check some of these with Alive to prove to myself it's right, but everything
seems to check out. Eg, the code in instcombine was completely ignoring predicates with
mismatched signedness.
Handling or-of-icmps would be a follow-up step.
Differential Revision: https://reviews.llvm.org/D32143
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301260 91177308-0d34-0410-b5e6-96231b3b80d8
Rely on MachineRegisterInfo's knowledge of used physical
registers.
Move flat_scratch initialization earlier, so the uses are visible
when making these decisions.
This will make it easier to add another reserved register
at the end for the stack pointer rather than handling another
special case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301254 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
That API creates a temporary AttributeList to carry an index and a
single AttributeSet. We need to carry the index in addition to the set,
because that is how attribute groups are currently encoded.
NFC
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32262
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301245 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Ensure that the new merge BB (which contains the rest of the original BB
after the mem op being optimized) gets a profile frequency, in case
there are additional mem ops later in the BB. Otherwise they get skipped
as the merge BB looks cold.
Reviewers: davidxl, xur
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32447
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301244 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r300732. This breaks a few tests.
I think the problem is related to adding more uses of
the condition that don't yet exist at this point.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301242 91177308-0d34-0410-b5e6-96231b3b80d8
The current Loop Unroll implementation works with loops having a
single latch that contains a conditional branch to a block outside
the loop (the other successor is, by defition of latch, the header).
If this precondition doesn't hold, avoid unrolling the loop as
the code is not ready to handle such circumstances.
Differential Revision: https://reviews.llvm.org/D32261
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301239 91177308-0d34-0410-b5e6-96231b3b80d8
Use constant references rather than `const auto` which will cause the
copy constructor. These particular cases cause issues for the swift
compiler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301237 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@301236 91177308-0d34-0410-b5e6-96231b3b80d8
