| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Instead of asserting when the kernel metadata is different than we expect,
we should just skip lowering that function. This fixes assertion
failures with OpenCL argument metadata from older LLVM releases.
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D13356
llvm-svn: 249073
|
| |
|
|
|
|
|
|
|
|
|
|
| |
v2: Add test (Matt).
Fix capitalization of isEOP (Matt).
Move pattern to class parameter (Matt).
Make the instruction available to Cayman (Matt).
Change name from MEM_RAT WRITE_TYPED to MEM_RAT STORE_TYPED.
Patch by: Zoltan Gilian
llvm-svn: 249042
|
| |
|
|
|
|
|
|
| |
v2: Fix brace placement and capitalization (Matt).
Patch by: Zoltan Gilian
llvm-svn: 249041
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D12451
llvm-svn: 248978
|
| |
|
|
|
|
|
|
|
|
| |
to prevent setting a huge stride, because DATA_FORMAT has a different
meaning if ADD_TID_ENABLE is set.
This is a candidate for stable llvm 3.7.
Tested-and-Reviewed-by: Christian König <christian.koenig@amd.com>
llvm-svn: 248858
|
| |
|
|
| |
llvm-svn: 248742
|
| |
|
|
|
|
|
|
| |
When used recursively, this would set the kill flag
on the intermediate step from first splitting
x16 to x8.
llvm-svn: 248741
|
| |
|
|
| |
llvm-svn: 248740
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The splitting of > 4 dword SMRD instructions
if using an offset in an SGPR instead of an immediate
was not setting the destination register,
resulting an an instruction missing an operand
which would assert later.
Test will be included in a following commit
which fixes a related issue.
llvm-svn: 248739
|
| |
|
|
|
|
|
|
|
|
| |
mem-folding&coalescing.
Patch by Slava Klochkov (vyacheslav.n.klochkov@intel.com)
Differential Revision: http://reviews.llvm.org/D11370
llvm-svn: 248735
|
| |
|
|
|
|
|
| |
Since this is only needed for VOP3 and a few other special
case instructions, stop setting it on everything.
llvm-svn: 248657
|
| |
|
|
|
|
| |
This gets isSGPRClass out of my profile of SIFixSGPRCopies.
llvm-svn: 248656
|
| |
|
|
|
|
|
| |
No tests hit these and it would be better to have checks like
this explicit where they are used.
llvm-svn: 248655
|
| |
|
|
|
|
| |
Add missing override. NFC.
llvm-svn: 248652
|
| |
|
|
|
|
|
|
| |
These require multiple mov instructions to copy,
but the default value is that 1 instruction is needed.
I'm not sure if this actually changes anything.
llvm-svn: 248651
|
| |
|
|
| |
llvm-svn: 248647
|
| |
|
|
|
|
|
|
| |
Trying to use the version with the explicit output operand
would complain because of the missing WriteSALU. I'm not sure
why it doesn't complain about this with the implicit VCC def.
llvm-svn: 248646
|
| |
|
|
|
|
|
|
|
| |
It's easier to understand creating a full instruction
than the current situation where sometimes a new
instruction is created and sometimes it is awkwardly
mutated in place.
llvm-svn: 248627
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm, grosbach, rafael
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D12424
llvm-svn: 248619
|
| |
|
|
|
|
| |
This matches how it is defined in the generated implementation.
llvm-svn: 248598
|
| |
|
|
|
|
|
|
|
|
|
| |
Don't run passes related to stack maps, garbage collection,
exceptions since these aren't useful for GPUs.
There might be a few more to turn off that I'm less sure about
(e.g. ShrinkWrapping) or I'm not sure how to disable
(SafeStack and StackProtector)
llvm-svn: 248591
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a select error when the i64 source was also
bitcasted to v2i32 in the original source.
Instead of awkwardly trying to select the modified source value and
the store, replace before isel begins.
Uses a worklist to avoid possible problems from mutating the DAG,
although it seems to work OK without it.
llvm-svn: 248589
|
| |
|
|
|
|
|
| |
SIFixSGPRCopies does not modify the CFG, but this was
being recomputed before running SIFoldOperands.
llvm-svn: 248587
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When buffer resource descriptors were built, the upper two components
of the descriptor were first composed into a 64-bit register because
legalizeOperands assumed all operands had the same register class.
Fix that problem, but keep the workaround. I'm not sure anything
actually is actually emitting such a REG_SEQUENCE now.
If multiple resource descriptors are set up with different base
pointers, this is copied with a single s_mov_b64. We probably
should fix this better by recognizing a pair of s_mov_b32 later,
but for now delete the dead code.
llvm-svn: 248585
|
| |
|
|
|
|
| |
This avoids needting to re-legalize the new REG_SEQUENCE.
llvm-svn: 248584
|
| |
|
|
|
|
|
|
|
| |
This was only set on the final _si/_vi version, but not
on the pseudos most of codegen sees.
No test since these instructions aren't used yet.
llvm-svn: 248583
|
| |
|
|
|
|
|
|
|
|
|
| |
These were all using the default 32-bit VALU write class,
but the i64/f64 compares are half rate.
I'm not sure this is really correct, because they are still using
the write to VALU write class, even though they really write
to the SALU.
llvm-svn: 248582
|
| |
|
|
| |
llvm-svn: 248553
|
| |
|
|
| |
llvm-svn: 248533
|
| |
|
|
|
|
|
|
|
|
| |
These are necessary for implementing mem_fence for
OpenCL 2.0.
The VI assembler tests are disabled since it seems to be
using the wrong encoding or opcode.
llvm-svn: 248532
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow a target to do something other than search for copies
that will avoid cross register bank copies.
Implement for SI by only rewriting the most basic copies,
so it should look through anything like a subregister extract.
I'm not entirely satisified with this because it seems like
eliminating a reg_sequence that isn't fully used should work
generically for all targets without them having to override
something. However, it seems to be tricky to have a simple
implementation of this without rewriting to invalid kinds
of subregister copies on some targets.
I'm not sure if there is currently a generic way to easily check
if a subregister index would be valid for the current use.
The current set of TargetRegisterInfo::get*Class functions don't
quite behave like I would expect (e.g. getSubClassWithSubReg
returns the maximal register class rather than the minimal), so
I'm not sure how to make the generic test keep searching if
SrcRC:SrcSubReg is a valid replacement for DefRC:DefSubReg. Making
the default implementation to check for simple copies breaks
a variety of ARM and x86 tests by producing illegal subregister uses.
The ARM tests are not actually changed since it should still be using
the same sharesSameRegisterFile implementation, this just relaxes
them to not check for specific registers.
llvm-svn: 248478
|
| |
|
|
| |
llvm-svn: 248476
|
| |
|
|
| |
llvm-svn: 248475
|
| |
|
|
| |
llvm-svn: 248474
|
| |
|
|
| |
llvm-svn: 248472
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of always inserting a copy in case
the super register is itself a subregister,
only extract to the super reg class if this is
actually the case.
This shouldn't really change codegen, but
makes looking at the output of SIFixSGPRCopies
easier to read.
llvm-svn: 248467
|
| |
|
|
| |
llvm-svn: 248264
|
| |
|
|
| |
llvm-svn: 248263
|
| |
|
|
| |
llvm-svn: 248262
|
| |
|
|
|
|
|
| |
If the instruction doesn't have enough operands, it
either shouldn't be marked as isCommutable or is malformed.
llvm-svn: 248242
|
| |
|
|
| |
llvm-svn: 248172
|
| |
|
|
|
|
| |
extra times. NFC
llvm-svn: 248140
|
| |
|
|
|
|
| |
coding standards. NFC
llvm-svn: 248136
|
| |
|
|
|
|
|
| |
getCFGStructurizerRegClass is not used for SI, so
move it into R600 specific stuff.
llvm-svn: 248087
|
| |
|
|
|
|
| |
propagate to all callers/users/etc.
llvm-svn: 247864
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After D10403, we had FMF in the DAG but disabled by default. Nick reported no crashing errors after some stress testing,
so I enabled them at r243687. However, Escha soon notified us of a bug not covered by any in-tree regression tests:
if we don't propagate the flags, we may fail to CSE DAG nodes because differing FMF causes them to not match. There is
one test case in this patch to prove that point.
This patch hopes to fix or leave a 'TODO' for all of the in-tree places where we create nodes that are FMF-capable. I
did this by putting an assert in SelectionDAG.getNode() to find any FMF-capable node that was being created without FMF
( D11807 ). I then ran all regression tests and test-suite and confirmed that everything passes.
This patch exposes remaining work to get DAG FMF to be fully functional: (1) add the flags to non-binary nodes such as
FCMP, FMA and FNEG; (2) add the flags to intrinsics; (3) use the flags as conditions for transforms rather than the
current global settings.
Differential Revision: http://reviews.llvm.org/D12095
llvm-svn: 247815
|
| |
|
|
|
|
|
|
| |
related. NFC.
Eric has replied and has demanded the patch be reverted.
llvm-svn: 247702
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and related. NFC.
Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).
For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.
This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.
This commit also contains a trivial patch to clang to account for the C++ API
change. Thanks go to Pavel Labath for fixing LLDB for me.
Reviewers: rengolin
Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10969
llvm-svn: 247692
|
| |
|
|
|
|
| |
LLDB needs to be updated in the same commit.
llvm-svn: 247686
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).
For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.
This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.
This commit also contains a trivial patch to clang to account for the C++ API
change.
Reviewers: rengolin
Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10969
llvm-svn: 247683
|