[Attributor][Fix] Manifest nocapture only in CSArgument or Argument
Summary:
We can query to Attributor whether the value is captured in the scope or not on the following way:
```
const auto & NoCapAA = A.getAAFor<AANoCapture>(*this, IRPosition::value(V));
```
And if V is CallSiteReturned then `getDeducedAttribute` will add `nocatpure` to the callsite returned value. It is not valid.
This patch checks the position is an argument or call site argument.
[Debuginfo][Instcombiner] Do not clone dbg.declare.
TryToSinkInstruction() has a bug: While updating debug info for
sunk instruction, it could clone dbg.declare intrinsic.
That is wrong. There could be only one dbg.declare.
The fix is to not clone dbg.declare intrinsic and to update
it`s arguments, to not to point to sunk instruction.
Petr Hosek [Wed, 11 Sep 2019 01:09:16 +0000 (01:09 +0000)]
clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM
This patch contains the basic functionality for reporting potentially
incorrect usage of __builtin_expect() by comparing the developer's
annotation against a collected PGO profile. A more detailed proposal and
discussion appears on the CFE-dev mailing list
(http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a
prototype of the initial frontend changes appear here in D65300
We revised the work in D65300 by moving the misexpect check into the
LLVM backend, and adding support for IR and sampling based profiles, in
addition to frontend instrumentation.
We add new misexpect metadata tags to those instructions directly
influenced by the llvm.expect intrinsic (branch, switch, and select)
when lowering the intrinsics. The misexpect metadata contains
information about the expected target of the intrinsic so that we can
check against the correct PGO counter when emitting diagnostics, and the
compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight.
We use these branch weight values to determine when to emit the
diagnostic to the user.
A future patch should address the comment at the top of
LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and
UnlikelyBranchWeight values into a shared space that can be accessed
outside of the LowerExpectIntrinsic pass. Once that is done, the
misexpect metadata can be updated to be smaller.
In the long term, it is possible to reconstruct portions of the
misexpect metadata from the existing profile data. However, we have
avoided this to keep the code simple, and because some kind of metadata
tag will be required to identify which branch/switch/select instructions
are influenced by the use of llvm.expect
Summary:
This commit is the final one for adding tapi support to the llvm-nm implementation.
This commit also has accompanying tests the additions to lib/Object
[GlobalISel] When a tail call is emitted in a block, stop translating it
This fixes a crash in tail call translation caused by assume and lifetime_end
intrinsics.
It's possible to have instructions other than a return after a tail call which
will still have `Analysis::isInTailCallPosition` return true. (Namely,
lifetime_end and assume intrinsics.)
If we emit a tail call, we should stop translating instructions in the block.
Otherwise, we can end up emitting an extra return, or dead instructions in
general. This makes the verifier unhappy, and is generally unfortunate for
codegen.
This also removes the code from AArch64CallLowering that checks if we have a
tail call when lowering a return. This is covered by the new code now.
Also update call-translator-tail-call.ll to show that we now properly tail call
in the presence of lifetime_end and assume.
[AArch64][GlobalISel] Support sibling calls with mismatched calling conventions
Add support for sibcalling calls whose calling convention differs from the
caller's.
- Port over `CCState::resultsCombatible` from CallingConvLower.cpp into
CallLowering. This is used to verify that the way the caller and callee CC
handle incoming arguments matches up.
- Add `CallLowering::analyzeCallResult`. This is basically a port of
`CCState::AnalyzeCallResult`, but using `ArgInfo` rather than `ISD::InputArg`.
- Add `AArch64CallLowering::doCallerAndCalleePassArgsTheSameWay`. This checks
that the calling conventions are compatible, and that the caller and callee
preserve the same registers.
For testing:
- Update call-translator-tail-call.ll to show that we can now handle this.
- Add a GISel line to tailcall-ccmismatch.ll to show that we will not tail call
when the regmasks don't line up.
Reland "Change the X86 datalayout to add three address spaces
for 32 bit signed, 32 bit unsigned, and 64 bit pointers."
This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5.
Original review at https://reviews.llvm.org/D64931.
Review for added fix at https://reviews.llvm.org/D66843.
Adding support for overriding LLVM_ENABLE_RUNTIMES for runtimes builds.
On some platforms, certain runtimes are not supported. For runtimes builds of
those platforms it would be nice if we could disable certain runtimes (ie
libunwind on Windows).
[MemorySSA] Do not create memoryaccesses for debug info intrinsics.
Summary:
Do not model debuginfo intrinsics in MemorySSA.
Regularly these are non-memory modifying instructions. With -disable-basicaa, they were being modelled as Defs.
Eric Christopher [Tue, 10 Sep 2019 22:05:01 +0000 (22:05 +0000)]
Move LLVM_ENABLE_ABI_BREAKING_CHECKS variables to their own file
so that you don't have to link Error.o and all of its dependencies.
In more detail: global initializers in Error.o can't be elided with
-ffunction-sections/-gc-sections since they always need to be run
causing a fairly significant binary bloat if all you want is the
ABI breaking checks code.
Philip Reames [Tue, 10 Sep 2019 21:12:29 +0000 (21:12 +0000)]
[ValueTracking] Factor our common speculation suppression logic [NFC]
Expose a utility function so that all places which want to suppress speculation (when otherwise legal) due to ordering and/or sanitizer interaction can do so.
Roman Lebedev [Tue, 10 Sep 2019 19:30:17 +0000 (19:30 +0000)]
[NFC][InstCombine] rewrite test added in r371537 to use non-null pointer instead
I only want to ensure that %offset is non-zero there,
it doesn't matter how that info is conveyed.
As filed in PR43267, the assumption way does not work.
Philip Reames [Tue, 10 Sep 2019 18:43:15 +0000 (18:43 +0000)]
[X86] Updated target specific selection dag code to conservatively check for isAtomic in addition to isVolatile
See D66309 for context.
This is the first sweep of x86 target specific code to add isAtomic bailouts where appropriate. The intention here is to have the switch from AtomicSDNode to LoadSDNode/StoreSDNode be close to NFC; that is, I'm not looking to allow additional optimizations at this time.
Sorry for the lack of tests. As discussed in the review, most of these are vector tests (for which atomicity is not well defined) and I couldn't figure out to exercise the anyextend cases which aren't vector specific.
Roman Lebedev [Tue, 10 Sep 2019 18:40:00 +0000 (18:40 +0000)]
[NFC][InstSimplify] rewrite test added in r371537 to use non-null pointer instead
I only want to ensure that %offset is non-zero there,
it doesn't matter how that info is conveyed.
As filed in PR43267, the assumption way does not work.
[BPI] Adjust the probability for floating point unordered comparison
Since NaN is very rare in normal programs, so the probability for floating point unordered comparison should be extremely small. Current probability is 3/8, it is too large, this patch changes it to a tiny number.
Matt Arsenault [Tue, 10 Sep 2019 17:19:46 +0000 (17:19 +0000)]
AMDGPU/GlobalISel: Select G_FABS/G_FNEG
f64 doesn't work yet because tablegen currently doesn't handlde
REG_SEQUENCE.
This does regress some multi use VALU fneg cases since now the
immediate remains in an SGPR, and more moves are used for legalizing
the xor. This is a SIFixSGPRCopies deficiency.
Sam Elliott [Tue, 10 Sep 2019 16:24:03 +0000 (16:24 +0000)]
[RISCV] Support llvm-objdump -M no-aliases and -M numeric
Summary:
Now that llvm-objdump allows target-specific options, we match the
`no-aliases` and `numeric` options for RISC-V, as supported by GNU objdump.
This is done by overriding the variables used for the command-line options, so
that the command-line options are still supported.
This patch updates all tests using `llvm-objdump -riscv-no-aliases` to use
`llvm-objdump -M no-aliases`.
Matt Arsenault [Tue, 10 Sep 2019 16:20:14 +0000 (16:20 +0000)]
AMDGPU/GlobalISel: First pass at attempting to legalize load/stores
There's still a lot more to do, but this handles decomposing due to
alignment. I've gotten it to the point where nothing crashes or
infinite loops the legalizer.
Sam Elliott [Tue, 10 Sep 2019 15:55:55 +0000 (15:55 +0000)]
[RISCV] Add Option for Printing Architectural Register Names
Summary:
This is an option primarily to use during testing. Instead of always
printing registers using their ABI names, this allows a user to request they
are printed with their architectural name.
This is then used in the register constraint tests to ensure the mapping
between architectural and abi names is correct.
The tool reports verbose output for the DWARF debug location coverage.
The llvm-locstats for each variable or formal parameter DIE computes what
percentage from the code section bytes, where it is in scope, it has
location description. The line 0 shows the number (and the percentage) of
DIEs with no location information, but the line 100 shows the number (and
the percentage) of DIEs where there is location information in all code
section bytes (where the variable or parameter is in the scope). The line
50..59 shows the number (and the percentage) of DIEs where the location
information is in between 50 and 59 percentage of its scope covered.
The tool will be very useful for tracking improvements regarding the
"debugging optimized code" support with LLVM ecosystem.
[InstCombine] Use SimplifyFMulInst to simplify multiply in fma.
This allows us to fold fma's that multiply with 0.0. Also, the
multiply by 1.0 case is handled there as well. The fneg/fabs cases
are not handled by SimplifyFMulInst, so we need to keep them.
Fix the "git modified" issue on the preserve-comments-crlf.s.
Summary:
rL371473 corrected the line ending (to crlf) in preserve-comments-crlf.s, but it causes a wired issue on git
repository (I ran git pull today, it showed a local change of that file even I did not change anything).
[Alignment][NFC] Use llvm::Align for TargetLowering::getPrefLoopAlignment
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Igor Kudrin [Tue, 10 Sep 2019 11:54:32 +0000 (11:54 +0000)]
Reland [DWARF] Add a unit test for DWARFUnit::getLength().
This is a follow-up of rL369529, where the return value of
DWARFUnit::getLength() was changed from uint32_t to uint64_t.
The test checks that a unit header with Length > 4G can be successfully
parsed and the value of the Length field is not truncated.
The additional fields will be parsed by the llvm-locstats tool in order to
produce more human readable output of the DWARF debug location quality
generated.
To prevent AArch64 tests from running when the target is not compiled.
Fixes r371502:
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/test/Transforms/ExpandMemCmp/AArch64/memcmp.ll:11:15: error: CHECK-NEXT: expected string not found in input
; CHECK-NEXT: [[TMP0:%.*]] = bitcast i8* [[S1:%.*]] to i64*
If we set p_align to 4, the PT_LOAD will be loaded at an address which
is a multiple of 4. The address of .text.hot is guaranteed to be a
multiple of 4, but not necessarily a multiple of 16.
Igor Kudrin [Tue, 10 Sep 2019 09:03:24 +0000 (09:03 +0000)]
[DWARF] Add a unit test for DWARFUnit::getLength().
This is a follow-up of rL369529, where the return value of
DWARFUnit::getLength() was changed from uint32_t to uint64_t.
The test checks that a unit header with Length > 4G can be successfully
parsed and the value of the Length field is not truncated.
[Alignment] Use Align for TargetLowering::MinStackArgumentAlignment
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
[LegalizeTypes] Teach SoftenFloatOp_SELECT_CC to handle operand 2 or 3 being softened.
This can only happen on X86 when fp128 is a legal type, but we
go through softening to generate libcalls. This causes fp128 to
be softened to fp128 instead of an integer type. This can be
removed if D67128 lands.
Petr Hosek [Tue, 10 Sep 2019 03:11:39 +0000 (03:11 +0000)]
clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM
This patch contains the basic functionality for reporting potentially
incorrect usage of __builtin_expect() by comparing the developer's
annotation against a collected PGO profile. A more detailed proposal and
discussion appears on the CFE-dev mailing list
(http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a
prototype of the initial frontend changes appear here in D65300
We revised the work in D65300 by moving the misexpect check into the
LLVM backend, and adding support for IR and sampling based profiles, in
addition to frontend instrumentation.
We add new misexpect metadata tags to those instructions directly
influenced by the llvm.expect intrinsic (branch, switch, and select)
when lowering the intrinsics. The misexpect metadata contains
information about the expected target of the intrinsic so that we can
check against the correct PGO counter when emitting diagnostics, and the
compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight.
We use these branch weight values to determine when to emit the
diagnostic to the user.
A future patch should address the comment at the top of
LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and
UnlikelyBranchWeight values into a shared space that can be accessed
outside of the LowerExpectIntrinsic pass. Once that is done, the
misexpect metadata can be updated to be smaller.
In the long term, it is possible to reconstruct portions of the
misexpect metadata from the existing profile data. However, we have
avoided this to keep the code simple, and because some kind of metadata
tag will be required to identify which branch/switch/select instructions
are influenced by the use of llvm.expect
[Windows] Replace TrapUnreachable with an int3 insertion pass
This is an alternative to D66980, which was reverted. Instead of
inserting a pseudo instruction that optionally expands to nothing, add a
pass that inserts int3 when appropriate after basic block layout.
LangRef: mention MSan's problem with speculative conditional branches.
Summary:
This short blurb aims to disallow optimizations like we had to revert
(under MSan) in
https://reviews.llvm.org/D21165
https://bugs.llvm.org/show_bug.cgi?id=28054
https://reviews.llvm.org/D67205
Philip Reames [Mon, 9 Sep 2019 20:54:13 +0000 (20:54 +0000)]
[LoopVectorize] Leverage speculation safety to avoid masked.loads
If we're vectorizing a load in a predicated block, check to see if the load can be speculated rather than predicated. This allows us to generate a normal vector load instead of a masked.load.
To do so, we must prove that all bytes accessed on any iteration of the original loop are dereferenceable, and that all loads (across all iterations) are properly aligned. This is equivelent to proving that hoisting the load into the loop header in the original scalar loop is safe.
Note: There are a couple of code motion todos in the code. My intention is to wait about a day - to be sure this sticks - and then perform the NFC motion without furthe review.
Philip Reames [Mon, 9 Sep 2019 20:26:52 +0000 (20:26 +0000)]
[Tests] Add anyextend tests for unordered atomics
Motivated by work on changing our representation of unordered atomics in SelectionDAG, but as an aside, all our lowerings for O3 are terrible. Even the ones which ignore the atomicity.
Philip Reames [Mon, 9 Sep 2019 19:23:22 +0000 (19:23 +0000)]
Introduce infrastructure for an incremental port of SelectionDAG atomic load/store handling
This is the first patch in a large sequence. The eventual goal is to have unordered atomic loads and stores - and possibly ordered atomics as well - handled through the normal ISEL codepaths for loads and stores. Today, there handled w/instances of AtomicSDNodes. The result of which is that all transforms need to be duplicated to work for unordered atomics. The benefit of the current design is that it's harder to introduce a silent miscompile by adding an transform which forgets about atomicity. See the thread on llvm-dev titled "FYI: proposed changes to atomic load/store in SelectionDAG" for further context.
Note that this patch is NFC unless the experimental flag is set.
The basic strategy I plan on taking is:
introduce infrastructure and a flag for testing (this patch)
Audit uses of isVolatile, and apply isAtomic conservatively*
piecemeal conservative* update generic code and x86 backedge code in individual reviews w/tests for cases which didn't check volatile, but can be found with inspection
flip the flag at the end (with minimal diffs)
Work through todo list identified in (2) and (3) exposing performance ops
(*) The "conservative" bit here is aimed at minimizing the number of diffs involved in (4). Ideally, there'd be none. In practice, getting it down to something reviewable by a human is the actual goal. Note that there are (currently) no paths which produce LoadSDNode or StoreSDNode with atomic MMOs, so we don't need to worry about preserving any behaviour there.
We've taken a very similar strategy twice before with success - once at IR level, and once at the MI level (post ISEL).
Matt Arsenault [Mon, 9 Sep 2019 18:57:51 +0000 (18:57 +0000)]
AMDGPU/GlobalISel: Legalize G_BUILD_VECTOR v2s16
Handle it the same way as G_BUILD_VECTOR_TRUNC. Arguably only
G_BUILD_VECTOR_TRUNC should be legal for this, but G_BUILD_VECTOR will
probably be more convenient in most cases.
Eli Friedman [Mon, 9 Sep 2019 18:29:27 +0000 (18:29 +0000)]
[IfConversion] Correctly handle cases where analyzeBranch fails.
If analyzeBranch fails, on some targets, the out parameters point to
some blocks in the function. But we can't use that information, so make
sure to clear it out. (In some places in IfConversion, we assume that
any block with a TrueBB is analyzable.)
The change to the testcase makes it trigger a bug on builds without this
fix: IfConvertDiamond tries to perform a followup "merge" operation,
which isn't legal, and we somehow end up with a branch to a deleted MBB.
I'm not sure how this doesn't crash the compiler.
Matt Arsenault [Mon, 9 Sep 2019 18:10:31 +0000 (18:10 +0000)]
AMDGPU: Use PatFrags to allow selecting custom nodes or intrinsics
This enables GlobalISel to handle various intrinsics. The custom node
pattern will be ignored, and the intrinsic will work. This will also
allow SelectionDAG to directly select the intrinsics, but as they are
all custom lowered to the nodes, this ends up leaving dead code in the
table.
Eventually either GlobalISel should add the equivalent of custom nodes
equivalent, or intrinsics should be directly used. These each have
different tradeoffs.
There are a few more to handle, but these are easy to handle
ones. Some others fail for other reasons.
projects / llvm / log