| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
It's possible to validly spill the frame offset register
in a call sequence to a VGPR. There are definitely issues
with SGPR spilling to memory, so move the assert later.
llvm-svn: 330612
|
| |
|
|
| |
llvm-svn: 330611
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use llvm-symbolizer in some production systems, and we run it
against all possibly related files, including some that are not
ELF. We noticed that for some of those invalid files, llvm-symbolizer
would crash with SEGFAULT. Here is an example of such a file.
It is due to that in computeSymbolSizes, a loop uses condition
for (unsigned I = 0, N = Addresses.size() - 1; I < N; ++I) {
where if Addresses.size() is 0, N would overflow and causing the loop
to access invalid memory.
Instead of patching the loop conditions, the commit makes so that the
function returns early if Addresses is empty.
Validated by checking that llvm-symbolizer no longer crashes.
Patch by Teng Qin!
Differential Revision: https://reviews.llvm.org/D44285
llvm-svn: 330610
|
| |
|
|
|
|
|
|
|
| |
Also assert that it is correct for SGPRs. There is currently a bug
where stack slot coloring replaces SGPR spill FIs with one with
the default ID, which results in a more confusing assert later
about a dead object.
llvm-svn: 330607
|
| |
|
|
| |
llvm-svn: 330606
|
| |
|
|
|
|
|
|
|
|
|
| |
Summary:
This just refactors the lowering of the atomic memory intrinsics to more
closely match the code patterns used in the lowering of the non-atomic
memory intrinsics. Specifically, we encapsulate the lowering in
SelectionDAG::getAtomicMem*() functions rather than embedding
the code directly in the SelectionDAGBuilder code.
llvm-svn: 330603
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Move Go bindings for subranges and DINode arrays.
Reviewers: harlanhaskins, whitequark, deadalnix
Reviewed By: whitequark
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45933
llvm-svn: 330594
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Adds bindings for Module and NameSpace scopes and LLVMDIBuilderCreateForwardDecl, a counterpart to LLVMDIBuilderCreateReplaceableCompositeType.
Reviewers: harlanhaskins, whitequark, deadalnix
Reviewed By: whitequark
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45934
llvm-svn: 330591
|
| |
|
|
|
|
| |
Note - noticed this as the STAC case as it was unintentionally matching against *STACK* pseudo instructions.
llvm-svn: 330588
|
| |
|
|
| |
llvm-svn: 330587
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Found by inspection. We care about the operand that *doesn't*
contain the immediate.
I believe this is currently not hit because we fold 0xff / 0xffff
immediates only later.
Change-Id: Ic3cf8538bc7da5eff3200d96eccf9d339e6345a7
Reviewers: arsenm, rampitec
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D45886
llvm-svn: 330586
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
See the new test case; this is really unlikely to happen with real code,
but I ran into this while attempting to bugpoint-reduce a different issue.
Change-Id: I9ade1dc1aa8fd9c4d9fc83661d7b80e310b5c4a6
Reviewers: arsenm, rampitec
Subscribers: kzhuravl, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Differential Revision: https://reviews.llvm.org/D45885
llvm-svn: 330585
|
| |
|
|
| |
llvm-svn: 330584
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
load instructions
Reviewers: fhahn, rengolin, javed.absar, huntergr, SjoerdMeijer, t.p.northover, echristo, evandro
Reviewed By: rengolin
Subscribers: tschuett, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D45684
llvm-svn: 330583
|
| |
|
|
|
|
|
|
|
|
|
| |
LoopRotate only invalidates innermost loops while the changes that it makes may
also affert any of this parents. With patch rL329047, SCEV becomes much smarter
about calculation of exit counts for outer loops, so we cannot assume that they are
not affected.
Differential Revision: https://reviews.llvm.org/D45945
llvm-svn: 330582
|
| |
|
|
| |
llvm-svn: 330581
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current runtime unrolling invalidates parent loop saying that it might have changed
after the inner loop has changed, but it doesn't bother to do the same to its parents.
With patch rL329047, SCEV becomes much smarter about calculation of exit counts for
outer loops. We might need to invalidate not only the immediate parent, but also
any of its parents as well.
There is no clear evidence that there is some miscompile happening because of this
(at least I don't have such test), but the common sense says that the current code
is wrong.
Differential Revision: https://reviews.llvm.org/D45940
Reviewed By: chandlerc
llvm-svn: 330577
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the function `simplifyOneLoop` we optimistically assume that changes in the
inner loop only affect this very loop and have no impact on its parents. In fact,
after rL329047 has been merged, we can now calculate exit counts for outer
loops which may depend on inner loops. Thus, we need to invalidate all parents
when we do something to a loop.
There is an evidence of incorrect behavior of `simplifyOneLoop`: when we insert
`SE->verify()` check in the end of this funciton, it fails on a bunch of existing
test, in particular:
LLVM :: Transforms/LoopUnroll/peel-loop-not-forced.ll
LLVM :: Transforms/LoopUnroll/peel-loop-pgo.ll
LLVM :: Transforms/LoopUnroll/peel-loop.ll
LLVM :: Transforms/LoopUnroll/peel-loop2.ll
Note that previously we have fixed issues of this variety, see rL328483.
This patch makes this function invalidate the outermost loop properly.
Differential Revision: https://reviews.llvm.org/D45937
Reviewed By: chandlerc
llvm-svn: 330576
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
store instructions.
Reviewers: fhahn, rengolin, javed.absar, SjoerdMeijer, t.p.northover, echristo, evandro, huntergr
Reviewed By: rengolin
Subscribers: tschuett, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D45681
llvm-svn: 330565
|
| |
|
|
|
|
|
|
| |
The condition this was asserting doesn't actually hold. I've added
comments to explain why, removed the assert, and added a fun test case
reduced out of 403.gcc.
llvm-svn: 330564
|
| |
|
|
| |
llvm-svn: 330563
|
| |
|
|
| |
llvm-svn: 330560
|
| |
|
|
| |
llvm-svn: 330558
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Wrap LLVMDIBuilderCreateAutoVariable, LLVMDIBuilderCreateParameterVariable, LLVMDIBuilderCreateExpression, and move and correct LLVMDIBuilderInsertDeclareBefore and LLVMDIBuilderInsertDeclareAtEnd from the Go bindings to the C bindings.
Reviewers: harlanhaskins, whitequark, deadalnix
Reviewed By: harlanhaskins, whitequark
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45928
llvm-svn: 330555
|
| |
|
|
|
|
| |
Fixed a lot of the default classes which were being completely overridden.
llvm-svn: 330554
|
| |
|
|
| |
llvm-svn: 330553
|
| |
|
|
| |
llvm-svn: 330552
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the last step in getting constant pattern matchers to allow
undef elements in constant vectors.
I'm adding a dedicated m_ZeroInt() function and building m_Zero() from
that. In most cases, calling code can be updated to use m_ZeroInt()
directly when there's no need to match pointers, but I'm leaving that
efficiency optimization as a follow-up step because it's not always
clear when that's ok.
There are just enough icmp folds in InstSimplify that can be used for
integer or pointer types, that we probably still want a generic m_Zero()
for those cases. Otherwise, we could eliminate it (and possibly add a
m_NullPtr() as an alias for isa<ConstantPointerNull>()).
We're conservatively returning a full zero vector (zeroinitializer) in
InstSimplify/InstCombine on some of these folds (see diffs in InstSimplify),
but I'm not sure if that's actually necessary in all cases. We may be
able to propagate an undef lane instead. One test where this happens is
marked with 'TODO'.
llvm-svn: 330550
|
| |
|
|
| |
llvm-svn: 330549
|
| |
|
|
| |
llvm-svn: 330548
|
| |
|
|
|
|
| |
to remove unnecessary instrw overrides.
llvm-svn: 330546
|
| |
|
|
| |
llvm-svn: 330545
|
| |
|
|
|
|
| |
This also fixes some of the ReadAfterLd issues due to InstRW.
llvm-svn: 330544
|
| |
|
|
|
|
| |
instrw overrides.
llvm-svn: 330542
|
| |
|
|
|
|
| |
latency.
llvm-svn: 330541
|
| |
|
|
|
|
|
| |
When a prefix is passed, we need to print a colon a space after it, not
just the prefix.
llvm-svn: 330535
|
| |
|
|
|
|
| |
This matches the other FENCE instructions.
llvm-svn: 330533
|
| |
|
|
|
|
| |
OpSizeFixed.
llvm-svn: 330532
|
| |
|
|
|
|
|
|
|
|
| |
'data32' in 16-bit mode. Hack the asm parser to convert 'data32' to 'data16' in 16-bit mode.
Improve the error messages to match GNU assembler.
This also allows us to remove the hack from the disassembler table building.
llvm-svn: 330531
|
| |
|
|
|
|
| |
scheduler models.
llvm-svn: 330527
|
| |
|
|
|
|
|
|
| |
Several tools prefix the error/warning/note output with the name of the
tool. One such tool is LLD for example. This commit adds as an optional
'Prefix' argument to the convenience helpers.
llvm-svn: 330526
|
| |
|
|
| |
llvm-svn: 330525
|
| |
|
|
|
|
| |
models.
llvm-svn: 330523
|
| |
|
|
|
|
| |
VPERM2I128/VINSERTI128
llvm-svn: 330522
|
| |
|
|
|
|
| |
pack/unpack instruction instrw overrides from scheduler models.
llvm-svn: 330521
|
| |
|
|
|
|
|
|
| |
PMULHW/PMULHUW.
Ultimately I want to use this to remove the intrinsics for these instructions.
llvm-svn: 330520
|
| |
|
|
| |
llvm-svn: 330517
|
| |
|
|
|
|
| |
overrides.
llvm-svn: 330514
|
| |
|
|
|
|
| |
D45629
llvm-svn: 330513
|
| |
|
|
|
|
|
|
| |
from scheduler models.
The required the default skylake schedules to be updated - these were being completely overriden by the InstRW and the existing values not used at all.
llvm-svn: 330510
|