This caused asserts in Chromium. See http://crbug.com/766261
> Summary:
> This comes up in optimized debug info for C++ programs that pass and
> return objects indirectly by address. In these programs,
> llvm.dbg.declare survives optimization, which causes us to emit indirect
> DBG_VALUE instructions. The fast register allocator knows to insert
> DW_OP_deref when spilling indirect DBG_VALUE instructions, but the
> LiveDebugVariables did not until this change.
>
> This fixes part of PR34513. I need to look into why this doesn't work at
> -O0 and I'll send follow up patches to handle that.
>
> Reviewers: aprantl, dblaikie, probinson
>
> Subscribers: qcolombet, hiraditya, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D37911
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313589 91177308-0d34-0410-b5e6-96231b3b80d8
NFC intended here, this only updates clang and lld's lit configs
to use some helper functionality in the lit.llvm submodule.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313579 91177308-0d34-0410-b5e6-96231b3b80d8
If we have an AssertZext of a truncated value that has already been AssertZext'ed,
we can assert on the wider source op to improve the zext-y knowledge:
assert (trunc (assert X, i8) to iN), i1 --> trunc (assert X, i1) to iN
This moves a fold from being Mips-specific to general combining, and x86 shows
improvements.
Differential Revision: https://reviews.llvm.org/D37017
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313577 91177308-0d34-0410-b5e6-96231b3b80d8
The code responsible for these transforms has the potential to add 2
instructions and break min/max patterns (PR33301).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313575 91177308-0d34-0410-b5e6-96231b3b80d8
rL310710 allowed store merging to occur after legalization to catch stores that are created late,
but this exposes a logic hole seen in PR34217:
https://bugs.llvm.org/show_bug.cgi?id=34217
We will miss merging stores if the target lowers vector extracts into target-specific operations.
This patch allows store merging to occur both before and after legalization if the target chooses
to get maximum merging.
I don't think the potential regressions in the other tests are relevant. The tests are for
correctness of weird IR constructs rather than perf tests, and I think those are still correct.
Differential Revision: https://reviews.llvm.org/D37987
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313564 91177308-0d34-0410-b5e6-96231b3b80d8
The AssertZext we might see in this case is only giving information about the lower 32 bits. It isn't providing information about the upper 32 bits. So we should emit a zext.
This fixes PR28540.
Differential Revision: https://reviews.llvm.org/D37729
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313563 91177308-0d34-0410-b5e6-96231b3b80d8
As commented on D37849, AVX1 targets were missing a chance to use vmovmskps for v8f32/v8i32 results for bool vector bitcasts
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313547 91177308-0d34-0410-b5e6-96231b3b80d8
For cases where we are BITCASTing to vectors of smaller elements, then if the entire source was a splatted sign (src's NumSignBits == SrcBitWidth) we can say that the dst's NumSignBit == DstBitWidth, as we're just splitting those sign bits across multiple elements.
We could generalize this but at the moment the only use case I have is to peek through bitcasts to vector comparison results.
Differential Revision: https://reviews.llvm.org/D37849
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313543 91177308-0d34-0410-b5e6-96231b3b80d8
The shuffle combining and lowerVectorShuffleAsLanePermuteAndBlend were both still trying to use VPERM2XF128 for unary shuffles when AVX2 is enabled. VPERM2X128 takes two inputs meaning when we use it for a unary shuffle one of those inputs is left undefined creating a false dependency on whatever register gets allocated there.
If we have VPERMQ/PD we should prefer those since they only have a single input.
Differential Revision: https://reviews.llvm.org/D37947
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313542 91177308-0d34-0410-b5e6-96231b3b80d8
This patch makes the `.eh_frame` extension an alias for `.debug_frame`.
Up till now it was only possible to dump the section using objdump, but
not with dwarfdump. Since the two are essentially interchangeable, we
dump whichever of the two is present.
As a workaround, this patch also adds parsing for 3 currently
unimplemented CFA instructions: `DW_CFA_def_cfa_expression`,
`DW_CFA_expression`, and `DW_CFA_val_expression`. Because I lack the
required knowledge, I just parse the fields without actually creating
the instructions.
Finally, this also fixes the typo in the `.debug_frame` section name
which incorrectly contained a trailing `s`.
Differential revision: https://reviews.llvm.org/D37852
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313530 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Subregister liveness tracking is not implemented for X86 backend, so
sometimes the whole super register is said to be live, when only a
subregister is really live. That might happen if the def and the use
are located in different MBBs, see added fixup-bw-isnt.mir test.
However, using knowledge of the specific instructions handled by the
bw-fixup-pass we can get more precise liveness information which this
change does.
Reviewers: MatzeB, DavidKreitzer, ab, andrew.w.kaylor, craig.topper
Reviewed By: craig.topper
Subscribers: n.bozhenov, myatsina, llvm-commits, hiraditya
Patch by Andrei Elovikov <andrei.elovikov@intel.com>
Differential Revision: https://reviews.llvm.org/D37559
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313524 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change adds support for explicit tail-exit records to be written by
the XRay runtime. This lets us differentiate the tail exit
records/events in the log, and allows us to treat those exit events
especially in the future. For now we allow printing those out in YAML
(and reading them in).
Reviewers: kpw, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37964
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313514 91177308-0d34-0410-b5e6-96231b3b80d8
MOVLHPS has a smaller encoding than UNPCKLPD in the legacy encodings. With VEX and EVEX encodings it doesn't matter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313509 91177308-0d34-0410-b5e6-96231b3b80d8
This patch supports all RV32I instructions as described in the RISC-V manual.
A future patch will add support for pseudoinstructions and other instruction
expansions (e.g. 0-arg fence -> fence iorw, iorw).
Differential Revision: https://reviews.llvm.org/D23566
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313485 91177308-0d34-0410-b5e6-96231b3b80d8
This was a bug in the test that was only exposed as a result of
refactoring some code in lit configuration files. Previously,
llvm's lit configuration would only set the target-windows feature
if the system was also windows. Since cross-compilation is
a thing, this isn't correct. target-windows should be set
independently of system-windows.
Adding to that bug, this particular test then checked for
target-windows when it really meant "can I call a certain API on
the host machine", which is what system-windows is for.
Ultimately, this test only works if *both* the target and host
are Windows, so I've updated the test to reflect that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313468 91177308-0d34-0410-b5e6-96231b3b80d8
There were some issues surrounding Py2 / Py3 compatibility, but
I've now tested with both Py2 and Py3 and everything seems to
work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313467 91177308-0d34-0410-b5e6-96231b3b80d8
This allows vector-sized store merging of constants in DAGCombiner using the existing code in MergeConsecutiveStores().
All of the twisted logic that decides exactly what vector operations are legal and fast for each particular CPU are
handled separately in there using the appropriate hooks.
For the motivating tests in merge-store-constants.ll, we already produce the same vector code in IR via the SLP vectorizer.
So this is just providing a backend backstop for code that doesn't go through that pass (-O1). More details in PR24449:
https://bugs.llvm.org/show_bug.cgi?id=24449 (this change should be the last step to resolve that bug)
Differential Revision: https://reviews.llvm.org/D37451
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313458 91177308-0d34-0410-b5e6-96231b3b80d8
We just need to toggle bits 1 and 5 of the immediate and swap the sources. The peephole pass could trigger commuting/folding for this later, but its easy enough to fix in isel.
Disable the peephole pass on the main vperm2x128 test so we know we're doing this through isel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313455 91177308-0d34-0410-b5e6-96231b3b80d8
I've moved the test cases from the InstCombine optimizations to the backend to keep the coverage we had there. It covered every possible immediate so I've preserved the resulting shuffle mask for each of those immediates.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313450 91177308-0d34-0410-b5e6-96231b3b80d8
I'm going to autoupgrade these intrinsics in a future commit. This bit will never be set in the resulting output so pre-removing the bit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313434 91177308-0d34-0410-b5e6-96231b3b80d8
