We were able to figure out that the result of a call is some constant.
While propagating that fact, we added the constant to the value map.
This is problematic because it results in us losing the call site when
processing the value map.
This fixes PR28802.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277611 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Thumb2 supports encoding immediates with specific patterns into mov.w by splatting the low 8 bits into other bytes.
Reviewers: john.brawn, jmolloy
Subscribers: jmolloy, aemerson, rengolin, samparker, llvm-commits
Differential Revision: https://reviews.llvm.org/D23090
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277610 91177308-0d34-0410-b5e6-96231b3b80d8
MappedBlockSTream can work with any sequence of block data where
the ordering is specified by a list of block numbers. So rather
than manually stitch them together in the case of the FPM, reuse
this functionality so that we can treat the FPM as if it were
contiguous.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D23066
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277609 91177308-0d34-0410-b5e6-96231b3b80d8
When expanding FP constants, we attempt to shrink doubles to floats and perform an extending load.
However, on SystemZ, and possibly on other targets (I've only confirmed the problem on SystemZ), the FP extending load instruction may convert SNaN into QNaN, or may cause an exception. So in the general case, we would still like to shrink FP constants, but SNaNs should be left as doubles.
Differential Revision: https://reviews.llvm.org/D22685
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277602 91177308-0d34-0410-b5e6-96231b3b80d8
When the same base address is used to load two different data types, LSR
would assume a memory type of "void". This type is not sized and has no
alignment information. Checking for it causes a crash.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277601 91177308-0d34-0410-b5e6-96231b3b80d8
called "FPM" instead of "LPM" in a hold-over from when the code was
modeled on that used to parse function passes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277584 91177308-0d34-0410-b5e6-96231b3b80d8
required by MSVC 2013.
This also makes the repeating pass wrapper assignable. Mildly
unfortunate as it means we can't use a const member for the int, but
that is a really minor invariant to try to preserve at the cost of loss
of regularity of the type. Yet another annoyance of the particular C++
object / move semantic model.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277582 91177308-0d34-0410-b5e6-96231b3b80d8
manager.
While this has some utility for debugging and testing on its own, it is
primarily intended to demonstrate the technique for adding custom
wrappers that can provide more interesting interation behavior in
a nice, orthogonal, and composable layer.
Being able to write these kinds of very dynamic and customized controls
for running passes was one of the motivating use cases of the new pass
manager design, and this gives a hint at how they might look. The actual
logic is tiny here, and most of this is just wiring in the pipeline
parsing so that this can be widely used.
I'm adding this now to show the wiring without a lot of business logic.
This is a precursor patch for showing how a "iterate up to N times as
long as we devirtualize a call" utility can be added as a separable and
composable component along side the CGSCC pass management.
Differential Revision: https://reviews.llvm.org/D22405
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277581 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We also add a test to show what currently happens when we create a
section per function and emit an xray_instr_map. This illustrates the
relationship (or lack thereof) between the per-function section and the
xray_instr_map section.
We also change the code generation slightly so that we don't always
create group sections, but rather only do so if a function where the
table is associated with is in a group.
Also in this change:
- Remove the "merge" flag on the xray_instr_map section.
- Test that we're generating the right table for comdat and non-comdat functions.
Reviewers: echristo, majnemer
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D23104
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277580 91177308-0d34-0410-b5e6-96231b3b80d8
IfConversion used to always add the undef flag when adding a use operand
on a newly predicated instruction. This would be an operand for the register
being conditionally redefined. Due to the undef flag, the liveness of this
register prior to the predicated instruction would get lost.
This patch changes this so that such use operands are added only when the
register is live, without the undef flag.
This was reverted but pushed again now, for details follow link below.
Reviewed by Quentin Colombet.
http://reviews.llvm.org/D209077
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277571 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is the first refactoring before adding new functionality.
Add a class wrapper for the functions and container for
state associated with the transformation.
No functional change
Reviewers: majnemer, nadav, mehdi_amini
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23065
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277565 91177308-0d34-0410-b5e6-96231b3b80d8
I forgot to do this initially, and added when I saw this fail in
a no-asserts build, but managed to loose the diff from the actual patch
that got submitted. Very sorry.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277562 91177308-0d34-0410-b5e6-96231b3b80d8
reason about and less error prone.
The core idea is to fully parse the text without trying to identify
passes or structure. This is done with a single state machine. There
were various bugs in the logic around this previously that were repeated
and scattered across the code. Having a single routine makes it much
easier to fix and get correct. For example, this routine doesn't suffer
from PR28577.
Then the actual pass construction is handled using *much* easier to read
code and simple loops, with particular pass manager construction sunk to
live with other pass construction. This is especially nice as the pass
managers *are* in fact passes.
Finally, the "implicit" pass manager synthesis is done much more simply
by forming "pre-parsed" structures rather than having to duplicate tons
of logic.
One of the bugs fixed by this was evident in the tests where we accepted
a pipeline that wasn't really well formed. Another bug is PR28577 for
which I have added a test case.
The code is less efficient than the previous code but I'm really hoping
that's not a priority. ;]
Thanks to Sean for the review!
Differential Revision: https://reviews.llvm.org/D22724
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277561 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a bug where we'd sometimes cache overly-conservative results
with our walker. This bug was made more obvious by r277480, which makes
our cache far more spotty than it was. Test case is llvm-unit, because
we're likely going to use CachingWalker only for def optimization in the
future.
The bug stems from that there was a place where the walker assumed that
`DefNode.Last` was a valid target to cache to when failing to optimize
phis. This is sometimes incorrect if we have a cache hit. The fix is to
use the thing we *can* assume is a valid target to cache to. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277559 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Sometimes, bitsets could get really large (>300k entries) and
we might want to drop a check, as it would have a too much cost.
Adding a flag to control how much penalty are we willing to pay
for bitsets.
Reviewers: kcc
Differential Revision: https://reviews.llvm.org/D23088
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277556 91177308-0d34-0410-b5e6-96231b3b80d8
Move those two options to llc:
The options in CommandFlags.h are shared by dsymutil, gold, llc,
llvm-dwp, llvm-lto, llvm-mc, lto, opt.
-stop-after/-start-after only affect codegen passes however only gold and llc
actually create codegen passes and I believe these flags to be only
useful for users of llc. For the other tools they are just highly
confusing: -stop-after claims to "Stop compilation after a specific
pass" which is not true in the context of the "opt" tool.
Differential Revision: https://reviews.llvm.org/D23050
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277551 91177308-0d34-0410-b5e6-96231b3b80d8
Leftover from D22686; the passes can handle all the instructions
unconditionally; only isel needs to care whether to generate them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277549 91177308-0d34-0410-b5e6-96231b3b80d8
I examined a few PDBs and all of them treated pages for stream 0
are unused, thus they were unmarked in their free page bitmap.
I think we should do the same thing for compatibility.
Differential Revision: https://reviews.llvm.org/D23047
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277545 91177308-0d34-0410-b5e6-96231b3b80d8
In this particular example we wouldn't want the smmls anyway (the value is
actually unused), but in general smmls does not provide the required flags
register so if that SUBE result is used we can't replace it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277541 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed the last incorrect uses of llvm_unreachable() in the code
which were actually just cases of errors in the input Archives.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277540 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Currently, the Scudo Hardened Allocator only gets its flags via the SCUDO_OPTIONS environment variable.
With this patch, we offer the opportunity for programs to define their own options via __scudo_default_options() which behaves like __asan_default_options() (weak symbol).
A relevant test has been added as well, and the documentation updated accordingly.
I also used this patch as an opportunity to rename a few variables to comply with the LLVM naming scheme, and replaced a use of Report with dieWithMessage for consistency (and to avoid a callback).
Reviewers: llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D23018
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277536 91177308-0d34-0410-b5e6-96231b3b80d8
There were issues with simply reporting AttrUnknown on
previously-unknown values in CFLAnders. So, we now act *entirely*
conservatively for values we haven't seen before. As in the prior patch
(r277362), writing a lit test for this isn't exactly trivial. If someone
wants a test badly, I'm willing to try to write one.
Patch by Jia Chen.
Differential Revision: https://reviews.llvm.org/D23077
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277533 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: We really want to move towards MemoryLocOrCall (or fix AA) everywhere, but for now, this lets us have a single instructionClobbersQuery.
Reviewers: george.burgess.iv
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23072
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277530 91177308-0d34-0410-b5e6-96231b3b80d8
As agreed in post-commit review of r265388, I'm switching the flag to
its original value until the 90% runtime performance regression on
SingleSource/Benchmarks/Stanford/Bubblesort is addressed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277524 91177308-0d34-0410-b5e6-96231b3b80d8
LLI already supported passing multiple input modules to MCJIT via the
-extra-module option. This patch adds the plumbing to pass these modules to
the OrcLazy JIT too.
This functionality will be used in an upcoming test case for weak symbol
handling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277521 91177308-0d34-0410-b5e6-96231b3b80d8
We were relying on the misleadingly-names $status result to actually be the
status. Actually it's just a scratch register that may or may not be valid (and
is the inverse of the real ststus anyway). Success can be determined by
comparing the value loaded against the one we wanted to see for "cmpxchg
strong" loops like this.
Should fix PR28819.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277513 91177308-0d34-0410-b5e6-96231b3b80d8
