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
1 out of the 4 tests commuted the operands, so there's an asymmetry
somewhere under this in how we handle these transforms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301125 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r301105, 4, 3 and 1, as a follow up of the previous
revert, which broke even more bots.
For reference:
Revert "[APInt] Use operator<<= where possible. NFC"
Revert "[APInt] Use operator<<= instead of shl where possible. NFC"
Revert "[APInt] Use ashInPlace where possible."
PR32754.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301111 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
D30400 has enabled tADC and tSBC instructions to be unglued, thereby allowing CPSR to remain live between Thumb1 scheduling units.
Most Thumb1 instructions have an OptionalDef for CPSR; but the scheduler ignored the OptionalDefs, and could unwittingly insert a flag-setting instruction in between an ADDS and the corresponding ADC.
Reviewers: javed.absar, atrick, MatzeB, t.p.northover, jmolloy, rengolin
Reviewed By: javed.absar
Subscribers: rogfer01, efriedma, aemerson, rengolin, llvm-commits, MatzeB
Differential Revision: https://reviews.llvm.org/D31081
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301106 91177308-0d34-0410-b5e6-96231b3b80d8
getRawData exposes the internal type of the APInt class directly to its users. Ideally we wouldn't expose such an implementation detail.
This patch fixes a few of the easy cases by using truncate, extract, or a rotate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301105 91177308-0d34-0410-b5e6-96231b3b80d8
... in the per-TU -O0 pipeline.
The problem is that there could be passes registered using
`addExtensionsToPM()` introducing unnamed globals.
Asan is an example, but there may be others. Building cppcheck
with `-flto=thin` and `-fsanitize=address` triggers an assertion
while we're reading bitcode (in lib/LTO), as the BitcodeReader
assumes there are no unnamed globals (because the namer has run).
Unfortunately I wasn't able to find an easy way to test this.
I added a comment in the hope nobody moves this again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301102 91177308-0d34-0410-b5e6-96231b3b80d8
For single word, shift by BitWidth was always returning 0, but for multiword it was based on original sign. Now single word matches multi word.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301094 91177308-0d34-0410-b5e6-96231b3b80d8
When the location description of a source variable involves arithmetic
on the value itself, it needs to be marked with DW_OP_stack_value since it
is not describing the variable's location, but rather its value.
This is a follow-up to r297971 and fixes the source testcase quoted in
the comment in debuginfo-dce.ll.
rdar://problem/30725338
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301093 91177308-0d34-0410-b5e6-96231b3b80d8
The unused upper bits are guaranteed to be 0 so we don't need to worry about accidentally counting them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301091 91177308-0d34-0410-b5e6-96231b3b80d8
The later uses of dyn_castNotVal in this block are either
incomplete (doesn't handle vector constants) or overstepping
(shouldn't handle constants at all), but this first use is
just unnecessary. 'I' is obviously not a constant, and it
can't be a not-of-a-not because that would already be
instsimplified.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301088 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
It functions just like RegisterClass except that the class is obtained
from a field.
Depends on D31761.
Reviewers: ab, qcolombet, t.p.northover, rovka, kristof.beyls, aditya_nandakumar
Reviewed By: ab
Subscribers: dberris, llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D32229
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301080 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Some targets need to be able to do more complex rendering than just adding an
operand or two to an instruction. For example, it may need to insert an
instruction to extract a subreg first, or it may need to perform an operation
on the operand.
In SelectionDAG, targets would create SDNode's to achieve the desired effect
during the complex pattern predicate. This worked because SelectionDAG had a
form of garbage collection that would take care of SDNode's that were created
but not used due to a later predicate rejecting a match. This doesn't translate
well to GlobalISel and the churn was wasteful.
The API changes in this patch enable GlobalISel to accomplish the same thing
without the waste. The API is now:
InstructionSelector::OptionalComplexRendererFn selectArithImmed(MachineOperand &Root) const;
where Root is the root of the match. The return value can be omitted to
indicate that the predicate failed to match, or a function with the signature
ComplexRendererFn can be returned. For example:
return OptionalComplexRendererFn(
[=](MachineInstrBuilder &MIB) { MIB.addImm(Immed).addImm(ShVal); });
adds two immediate operands to the rendered instruction. Immed and ShVal are
captured from the predicate function.
As an added bonus, this also reduces the amount of information we need to
provide to GIComplexOperandMatcher.
Depends on D31418
Reviewers: aditya_nandakumar, t.p.northover, qcolombet, rovka, ab, javed.absar
Reviewed By: ab
Subscribers: dberris, kristof.beyls, igorb, llvm-commits
Differential Revision: https://reviews.llvm.org/D31761
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301079 91177308-0d34-0410-b5e6-96231b3b80d8
canMutate() was returning true when the operands were all in the same order as
the matched instruction. However, it wasn't checking the operands were actually
on that instruction. This worked when we could only match a single instruction
but the addition of nested instruction matching led to cases where the operands
could be split across multiple instructions. canMutate() now returns false if
operands belong to instructions other than the root of the match.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301077 91177308-0d34-0410-b5e6-96231b3b80d8
In dwo files the fixed offset can be used - if the dwos are linked into
a dwp, the dwo consumer must use the dwp tables to find out where the
original range of the debug_info was and resolve the "section relative"
value relative to that original range - effectively
avoiding/reimplementing the relocation handling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301072 91177308-0d34-0410-b5e6-96231b3b80d8
The bug was introduced by r301018 "[InstCombine] fadd double (sitofp x), y check that the promotion is valid". The patch didn't expect that fadd can be on vectors not necessarily scalars. Add vector support along with the test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301070 91177308-0d34-0410-b5e6-96231b3b80d8
If a switch was in an unreachable block that branched
to a block with a phi, it would leave phis with missing
predecessors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301064 91177308-0d34-0410-b5e6-96231b3b80d8
Since Split DWARF needs to name the actual .dwo file that is generated,
it can't be known at the time the llvm::Module is produced as it may be
merged with other Modules before the object is generated and that object
may be generated with any name.
By passing the Split DWARF file name when LLVM is producing object code
the .dwo file name in the object file can match correctly.
The support for Split DWARF for implicit modules remains the same -
using metadata to store the dwo name and dwo id so that potentially
multiple skeleton CUs referring to different dwo files can be generated
from one llvm::Module.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301062 91177308-0d34-0410-b5e6-96231b3b80d8
