| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
No real functionality change here, just avoiding an unnecessary copy of
std::vector<TrackingMDRef> for every subprogram with variables.
llvm-svn: 266907
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is done for consistency with asan-use-after-return.
I see no other users than tests.
Reviewers: aizatsky, kcc
Differential Revision: http://reviews.llvm.org/D19306
llvm-svn: 266906
|
|
|
|
| |
llvm-svn: 266905
|
|
|
|
|
|
| |
Phabricator Revision: http://reviews.llvm.org/D19277
llvm-svn: 266904
|
|
|
|
| |
llvm-svn: 266903
|
|
|
|
|
|
|
|
| |
A ModuleSlotTracker can be created without actually being used (e.g.,
r266889 added one to the Verifier). Create the SlotTracker within it
lazily on the first call to ModuleSlotTracker::getMachine.
llvm-svn: 266902
|
|
|
|
| |
llvm-svn: 266901
|
|
|
|
|
|
| |
I missed this site in r266889.
llvm-svn: 266900
|
|
|
|
|
|
|
|
| |
Differentiate between word and subword memory operations as they take different
amount of cycles to complete. This just adds a basic model of the subword
latency to the scheduler.
llvm-svn: 266898
|
|
|
|
| |
llvm-svn: 266897
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19334
llvm-svn: 266895
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clients may call writeMergedModules before calling optimize, or call
compileOptimized without calling optimize. Make sure they don't sneak
past the verifier. This adds LTOCodeGenerator::verifyMergedModuleOnce,
and calls it from writeMergedModule, optimize, and codegenOptimized.
I couldn't find a good way to test this. I tried writing broken IR to
send into llvm-lto, but LTOCodeGenerator doesn't understand textual IR,
and assembler runs the verifier itself anyway. Checking in
valid-but-doesn't-verify bitcode here doesn't seem valuable.
llvm-svn: 266894
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function or not.
The alias handling was specific to the old iterative inlining
mechanism, so that is dead now. The variable handling could make a
difference, since we were previously falling through to the normal
selection logic, but we don't observe changes in the validation
because no client seems to rely on it.
Differential Revision: http://reviews.llvm.org/D19307
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266893
|
|
|
|
|
|
|
|
|
|
|
|
| |
Speed up Verifier output by sharing a single ModuleSlotTracker for the
duration. There should be no functionality change here except for much
faster output when there's more than one statement.
Now the Verifier won't be traversing the full Metadata graph every time
it prints an error. The TypePrinter is still not shared, but that would
take some extra plumbing.
llvm-svn: 266889
|
|
|
|
|
|
|
|
| |
While using a raw_null_ostream meant that the Verifier didn't have to
think about whether to print, it's actually quite expensive to print out
IR. Only print if the output is going somewhere.
llvm-svn: 266884
|
|
|
|
| |
llvm-svn: 266883
|
|
|
|
|
|
| |
Patch by Colin LeMahieu.
llvm-svn: 266882
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch prevents importing from (and therefore exporting from) any
module with a "llvm.used" local value. Local values need to be promoted
and renamed when importing, and their presense on the llvm.used variable
indicates that there are opaque uses that won't see the rename. One such
example is a use in inline assembly.
See also the discussion at:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098047.html
As part of this, move collectUsedGlobalVariables out of Transforms/Utils
and into IR/Module so that it can be used more widely. There are several
other places in LLVM that used copies of this code that can be cleaned
up as a follow on NFC patch.
Reviewers: joker.eph
Subscribers: pcc, llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D18986
llvm-svn: 266877
|
|
|
|
|
|
| |
This only affects the recomputation of kill flags.
llvm-svn: 266875
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14206
llvm-svn: 266873
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add ParseAMDGPURegister which can be invoked recursively for parsing lists.
Rename getRegForName to getSpecialRegForName.
Support legacy SP3 register list syntax: [s2,s3,s4,s5] or [flat_scratch_lo,flat_scratch_hi].
Add 64-bit registers TBA, TMA where missing.
Add some tests.
Differential Revision: http://reviews.llvm.org/D19163
llvm-svn: 266865
|
|
|
|
|
|
|
|
| |
Call locally defined function directly for PIE/fPIE
Differential Revision: http://reviews.llvm.org/D19226
llvm-svn: 266863
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18640
llvm-svn: 266861
|
|
|
|
| |
llvm-svn: 266858
|
|
|
|
|
|
|
|
|
| |
This linkage is *not* intended to express that a declaration refers
to a weak symbol, but that the symbol might not be present at link
time. I don't believe it was the intent.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266856
|
|
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266854
|
|
|
|
|
|
| |
vector types as Expand in a floating point only loop instead of looping through all vector types.
llvm-svn: 266850
|
|
|
|
|
|
| |
marked Legal or Promote for all the legal types later. Shifts are always marked custom. NFC
llvm-svn: 266849
|
|
|
|
|
|
| |
constructor. Also qualfiy the XOP block with !useSoftFloat to match the other vector blocks.
llvm-svn: 266848
|
|
|
|
|
|
| |
every legal FP type we either set them to Legal or Custom anyway. So let them stay defaulted to Legal and only change when they need to be Custom.
llvm-svn: 266847
|
|
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266845
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19054
llvm-svn: 266844
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
from LLVMAttribute
Summary:
LLVMAttribute has outlived its utility and is becoming a problem for C API users that what to use all the LLVM attributes. In order to help moving away from LLVMAttribute in a smooth manner, this diff introduce LLVMGetAttrKindIDInContext, which can be used instead of the enum values.
See D18749 for reference.
Reviewers: Wallbraker, whitequark, joker.eph, echristo, rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19081
llvm-svn: 266842
|
|
|
|
|
|
| |
[-Wdocumentation]
llvm-svn: 266841
|
|
|
|
|
|
| |
it will help finding leaks while fuzzing
llvm-svn: 266838
|
|
|
|
|
|
|
| |
to a member
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266837
|
|
|
|
|
|
|
|
|
| |
We never use the set-ness of SmallPtrSet for distinct nodes. Eventually
we may start garbage-collecting or reference-counting nodes (in which
cases we'd want to remove things from this collection, and a fast erase
would be valuable), but in the meantime a vector is sufficient.
llvm-svn: 266835
|
|
|
|
|
|
|
|
| |
Ugh.
Differential Revision: http://reviews.llvm.org/D19292
llvm-svn: 266833
|
|
|
|
|
|
|
|
| |
Because lowering of CMP_SWAP_64 occurs during type legalization, there can be
i64 types produced by more than just a BUILD_PAIR or similar. My initial tests
used just incoming function args.
llvm-svn: 266828
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This property is used to mark an intrinsic that only writes to memory, but
neither reads from memory nor has other side effects.
An example where this is useful is the llvm.amdgcn.buffer.store.format.*
intrinsic, which corresponds to a store instruction that goes through a special
buffer descriptor rather than through a plain pointer.
With this property, the intrinsic should still be handled as having side
effects at the LLVM IR level, but machine scheduling can make smarter
decisions.
Reviewers: tstellarAMD, arsenm, joker.eph, reames
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D18291
llvm-svn: 266826
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The added testcase, which triggered this, was derived from a shader-db case
via bugpoint. A separate question is why scalar branching wasn't used.
Reviewers: arsenm, tstellarAMD
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D19208
llvm-svn: 266825
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A shader stored the live mask (initial exec mask) in an SGPR which was then
spilled during register allocation. The allocator quite reasonably
optimized turned the spill into
v_writelane_b32 %vgpr, exec_lo, N
v_writelane_b32 %vgpr, exec_hi, N+1
at the beginning of the shader, confusing the SGPR accounting.
No test case, because si-sgpr-spill.ll together with an upcoming patch for
WQM handling exhibits the problem.
Reviewers: arsenm, tstellarAMD
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D19199
llvm-svn: 266824
|
|
|
|
|
|
| |
Also, disable zero- and size-extend optimizations for now.
llvm-svn: 266821
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both AArch64 and ARM support llvm.<arch>.thread.pointer intrinsics that
just return the thread pointer. I have a pending patch that does the same
for SystemZ (D19054), and there are many more targets that could benefit
from one.
This patch merges the ARM and AArch64 intrinsics into a single target
independent one that will also be used by subsequent targets.
Differential Revision: http://reviews.llvm.org/D19098
llvm-svn: 266818
|
|
|
|
| |
llvm-svn: 266811
|
|
|
|
| |
llvm-svn: 266809
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, ideally IR pass can always generate llvm.stackguard
call to get the stack guard; but for now there are still IR form stack
guard customizations around (see getIRStackGuard()). Future SSP
customization should go through LOAD_STACK_GUARD.
There is a behavior change: stack guard values are not CSEed anymore,
since we should never reuse the value in case that it has been spilled (and
corrupted). See ssp-guard-spill.ll. This also cause the change of stack
size and codegen in X86 and AArch64 test cases.
Ideally we'd like to know if the guard created in llvm.stackprotector() gets
spilled or not. If the value is spilled, discard the value and reload
stack guard; otherwise reuse the value. This can be done by teaching
register allocator to know how to rematerialize LOAD_STACK_GUARD and
force a rematerialization (which seems hard), or check for spilling in
expandPostRAPseudo. It only makes sense when the stack guard is a global
variable, which requires more instructions to load. Anyway, this seems to go out
of the scope of the current patch.
llvm-svn: 266806
|
|
|
|
|
|
|
|
| |
* Add lowering for SETCCE i32.
* Add test to check lowering of i64 compares uses SETCCE expansion (outside of EQ and NE).
* Fix select.ll test and immediate form selection for RI operations.
llvm-svn: 266802
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The functionality contained within getIntrinsicIDForCall is two-fold: it
checks if a CallInst's callee is a vectorizable intrinsic. If it isn't
an intrinsic, it attempts to map the call's target to a suitable
intrinsic.
Move the mapping functionality into getIntrinsicForCallSite and rename
getIntrinsicIDForCall to getVectorIntrinsicIDForCall while
reimplementing it in terms of getIntrinsicForCallSite.
llvm-svn: 266801
|
|
|
|
|
|
|
|
| |
- Elide trivial contructor and desctructor
- Move implementation out of an unnecessary explicit llvm namespace
scope
llvm-svn: 266794
|