Summary:
For some reason the backend assumed that the condition mask would be
the first argument to the LLVM intrinsic, but everywhere else the
condition mask is the third argument.
Reviewers: aheejin
Subscribers: dschuff, sbc100, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D56412
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350746 91177308-0d34-0410-b5e6-96231b3b80d8
On AIX, attempting (without root) to set the sticky bit on a file with
the `chmod` utility will give:
```
chmod: not all requested changes were made to <file>
```
The same occurs when modifying other permission bits on a file with the
sticky bit already set.
It seems that the `chmod` function will report success despite failing
to set the sticky bit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350735 91177308-0d34-0410-b5e6-96231b3b80d8
NVPTX format requires that no labels/label arithmetics is used in the
debug info sections. To avoid possible problems with the adding/modifying the debug info functionality, made these tests more strict.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350731 91177308-0d34-0410-b5e6-96231b3b80d8
This is an initial implementation for Speculative Load Hardening for
AArch64. It builds on top of the recently introduced
AArch64SpeculationHardening pass.
This doesn't implement (yet) some of the optimizations implemented for
the X86SpeculativeLoadHardening pass. I thought introducing the
optimizations incrementally in follow-up patches should make this easier
to review.
Differential Revision: https://reviews.llvm.org/D55929
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350729 91177308-0d34-0410-b5e6-96231b3b80d8
When GNU objdump dumps the input with -d it prints the symbol addresses,
for example:
0000000000000031 <foo>:
31: 00 00 add %al,(%rax)
...
llvm-objdump currently does not do that.
Patch changes the behavior to match the GNU objdump.
That is useful for implementing -z/--disassemble-zeroes (D56083),
it allows omitting first zero bytes and keep the information
about the symbol address in the output.
Differential revision: https://reviews.llvm.org/D56123
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350726 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed issue with identity values and other cases, f32/f16 identity values to be added later. fma/mac instructions is disabled for now.
Test is fully reworked, added comments. Other fixes:
1. dpp move with uses and old reg initializer should be in the same BB.
2. bound_ctrl:0 is only considered when bank_mask and row_mask are fully enabled (0xF). Othervise the old register value is checked for identity.
3. Added add, subrev, and, or instructions to the old folding function.
4. Kill flag is cleared for the src0 (DPP register) as it may be copied into more than one user.
Differential revision: https://reviews.llvm.org/D55444
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350721 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This fixes PR39710. In that case we emitted a location list looking like
this:
.Ldebug_loc0:
.quad .Lfunc_begin0-.Lfunc_begin0
.quad .Lfunc_begin0-.Lfunc_begin0
.short 1 # Loc expr size
.byte 85 # DW_OP_reg5
.quad .Lfunc_begin0-.Lfunc_begin0
.quad .Lfunc_end0-.Lfunc_begin0
.short 1 # Loc expr size
.byte 85 # super-register DW_OP_reg5
.quad 0
.quad 0
As seen, the first entry's beginning and ending addresses evalute to 0,
which meant that the entry inadvertently became an "end of list" entry,
resulting in the location list ending sooner than expected.
To fix this, omit all entries with empty ranges. Location list entries
with empty ranges do not have any effect, as specified by DWARF, so we
might as well drop them:
"A location list entry (but not a base address selection or end of list
entry) whose beginning and ending addresses are equal has no effect
because the size of the range covered by such an entry is zero."
Reviewers: davide, aprantl, dblaikie
Reviewed By: aprantl
Subscribers: javed.absar, JDevlieghere, llvm-commits
Tags: #debug-info
Differential Revision: https://reviews.llvm.org/D55919
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350698 91177308-0d34-0410-b5e6-96231b3b80d8
Current strategy of dropping `InstructionPrecedenceTracking` cache is to
invalidate the entire basic block whenever we change its contents. In fact,
`InstructionPrecedenceTracking` has 2 internal strictures: `OrderedInstructions`
that is needed to be invalidated whenever the contents changes, and the map
with first special instructions in block. This second map does not need an
update if we add/remove a non-special instuction because it cannot
affect the contents of this map.
This patch changes API of `InstructionPrecedenceTracking` so that it now
accounts for reasons under which we invalidate blocks. This should lead
to much less recalculations of the map and should save us some compile time
because in practice we don't typically add/remove special instructions.
Differential Revision: https://reviews.llvm.org/D54462
Reviewed By: efriedma
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350694 91177308-0d34-0410-b5e6-96231b3b80d8
When the result type is v2i64/v2f64 and the index element size is i32, the index vector has two unused elements making the type v4i32. The mask VT should match the number of memory accesses that will be made.
This is consistent with the isel patterns used for the target independent gather/scatter intrinsic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350687 91177308-0d34-0410-b5e6-96231b3b80d8
Convert the output of "git rev-parse --short HEAD" to a string before
substituting it into the output file. Without this the output file
will look like this on Python 3:
#define LLVM_REVISION "git-b'6a4895a025f'"
Differential Revision: https://reviews.llvm.org/D56459
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350686 91177308-0d34-0410-b5e6-96231b3b80d8
Bad machine code: Illegal virtual register for instruction
function: TestULE
basic block: %bb.0 entry (0x1000a39b158)
instruction: %2:crrc = FCMPUD %1:vsfrc, %3:f8rc
operand 1: %1:vsfrc
Fix assert about missing match between fcmp instruction and register class.
We should use vsx related cmp instruction xvcmpudp instead of fcmpu when vsx is opened.
add -verifymachineinstrs option into related test cases to enable the verify pass.
Differential Revision: https://reviews.llvm.org/D55686
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350685 91177308-0d34-0410-b5e6-96231b3b80d8
This removes check for single use from general ShrinkDemandedConstant
to the BE because of the AArch64 regression after D56289/rL350475.
After several hours of experiments I did not come up with a testcase
failing on any other targets if check is not performed.
Moreover, direct call to ShrinkDemandedConstant is not really needed
and superceed by SimplifyDemandedBits.
Differential Revision: https://reviews.llvm.org/D56406
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350684 91177308-0d34-0410-b5e6-96231b3b80d8
Currently it's possible for following
check on V.WriteLanes (which is not really meaningful
during SubRangeJoin) to pass for one half of the pair,
and then fall through to to one of the impossible
or unresolved states. This then fails as inconsistent
on the other half.
During the main range join, the check between V.WriteLanes
and OtherV.ValidLanes must have passed, meaning this
should be a CR_Replace.
Fixes most of the testcases in bugs 39542 and 39602
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350678 91177308-0d34-0410-b5e6-96231b3b80d8
We can't go back and recover the lanes if it turns
out the implicit_def really can't be erased.
Assume all lanes are valid if an unresolved conflict
is encountered. There aren't any tests where this
seems to matter either way, but this seems like a
safer option.
Fixes bug 39602
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350676 91177308-0d34-0410-b5e6-96231b3b80d8
This patch improves llvm-profdata show command:
(1) add -value-cutoff=<N> option: Show only those functions whose max count
values are greater or equal to N.
(2) add -list-below-cutoff option: Only output names of functions whose max
count value are below the cutoff.
(3) formats value-profile counts and prints out percentage.
Differential Revision: https://reviews.llvm.org/D56342
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350673 91177308-0d34-0410-b5e6-96231b3b80d8
This is matching the equivalent of the DAG expansion,
so it should never end up with worse perf than the
original code even if the target doesn't have a rotate
instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350672 91177308-0d34-0410-b5e6-96231b3b80d8
In LTO or Thin-lto mode (though linker plugin), the module
names are of temp file names which are different for
different compilations. Using SourceFileName avoids the issue.
This should not change any functionality for current PGO as
all the current callers of getPGOFuncName() is before LTO.
Differential Revision: https://reviews.llvm.org/D56327
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350671 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
StoreResults pass does not optimize store instructions anymore because
store instructions don't return results values anymore. Now this pass is
used solely for memory intrinsics, so update the pass name accordingly
and fix outdated pass descriptions as well.
This patch does not change any meaningful behavior, but not marked as
NFC because it changes a comment check line in a test case.
Reviewers: dschuff
Subscribers: mgorny, sbc100, jgravelle-google, sunfiish, llvm-commits
Differential Revision: https://reviews.llvm.org/D56093
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350669 91177308-0d34-0410-b5e6-96231b3b80d8
Starting in C++17, MSVC introduced a new mangling for function
parameters that are themselves noexcept functions. This patch
makes llvm-undname properly demangle them.
Patch by Zachary Henkel
Differential Revision: https://reviews.llvm.org/D55769
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@350656 91177308-0d34-0410-b5e6-96231b3b80d8
Easwaran Raman