| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
This avoids needting to re-legalize the new REG_SEQUENCE.
llvm-svn: 248584
|
| |
|
|
| |
llvm-svn: 248476
|
| |
|
|
| |
llvm-svn: 248475
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
If the instruction doesn't have enough operands, it
either shouldn't be marked as isCommutable or is malformed.
llvm-svn: 248242
|
| |
|
|
| |
llvm-svn: 247230
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Instead of extracting both 32-bit components from the 128-bit
register. This produces fewer copies and is easier for
the copy peephole optimizer to understand and see the actual uses
as extracts from a reg_sequence.
This avoids needing to handle subregister composing in the
PeepholeOptimizer's ValueTracker for this case.
llvm-svn: 247162
|
| |
|
|
|
|
|
| |
These are already added during the MachineInstr construction,
so this was adding the implicit registers twice.
llvm-svn: 246525
|
| |
|
|
| |
llvm-svn: 246357
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Without a memory operand, mayLoad or mayStore instructions
are treated as hasUnorderedMemRef, which results in much worse
scheduling.
We really should have a verifier check that any
non-side effecting mayLoad or mayStore has a memory operand.
There are a few instructions (interp and images) which I'm
not sure what / where to add these.
llvm-svn: 246356
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is no context where s_mov_b64 is emitted
and could potentially be moved to the VALU.
It is currently only emitted for materializing
immediates, which can't be dependent on vector sources.
The immediate splitting is already done when selecting
constants. I'm not sure what contexts if any the register
splitting would have been used before.
Also clean up using s_mov_b64 in place of v_mov_b64_pseudo,
although this isn't required and just skips the extra step
of eliminating the copy from the SReg_64.
llvm-svn: 246080
|
| |
|
|
| |
llvm-svn: 246079
|
| |
|
|
|
|
|
| |
This wouldn't propagate to users of the original BFE
and would hit a verifier error.
llvm-svn: 246078
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When splitting 64-bit operations, create the correct
VALU instructions immediately.
This was splitting things like s_or_b64 into the two
s_or_b32s and then pushing the new instructions
onto the worklist. There's no reason we need
to do this intermediate step.
llvm-svn: 246077
|
| |
|
|
| |
llvm-svn: 244402
|
| |
|
|
| |
llvm-svn: 244380
|
| |
|
|
|
|
| |
For the same reasons as the other physical registers.
llvm-svn: 244062
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes a bug in the class 'SIInstrInfo' where the implicit register
machine operands were added to a machine instruction in an incorrect order -
the implicit uses were added before the implicit defs.
I found this bug while working on moving the implicit register operand
verification code from the MIR parser to the machine verifier.
This commit also makes the method 'addImplicitDefUseOperands' in the machine
instruction class public so that it can be reused in the 'SIInstrInfo' class.
Reviewers: Matt Arsenault
Differential Revision: http://reviews.llvm.org/D11689
llvm-svn: 243799
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Replace the switch on instruction opcode with a switch on register size.
This way we don't need to update the switch statement when we add new
SMRD variants.
Reviewers: arsenm
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11601
llvm-svn: 243652
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This function is never called. isReallyTriviallyReMaterializable() is
the function that should be implemented instead.
Reviewers: arsenm
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11620
llvm-svn: 243651
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the read2 produced was supposed to be writing into a
super register, it would use the wrong subregister indices.
Fix this by inserting copies, so we only ever write to a vreg_64.
Run the register coalescer again to clean this up, although this
isn't ideal and often does result in an extra move.
Also remove the assert that offset1 > offset0.
There isn't a real reason to not allow this other than a minor
convenience in the compiler, and it doesn't seem worth the effort
of avoiding it.
llvm-svn: 242174
|
| |
|
|
|
|
|
|
|
| |
The two-address instruction pass will convert these back to v_mad_f32
if necessary.
Differential Revision: http://reviews.llvm.org/D11060
llvm-svn: 242038
|
| |
|
|
|
|
|
| |
No test case for this. I ran into it while working on some improvements
to SIShrinkInstructions.cpp.
llvm-svn: 241816
|
| |
|
|
|
|
|
|
|
|
| |
Summary: We need to set MTYPE = 2 for VI shaders when targeting the HSA runtime.
Reviewers: arsenm
Differential Revision: http://reviews.llvm.org/D10777
llvm-svn: 240841
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If pseudoToMCOpcode failed, we would return the original opcode, so operands
would be swapped, but the instruction would remain the same.
It resulted in LSHLREV a, b ---> LSHLREV b, a.
This fixes Glamor text rendering and
piglit/arb_sample_shading-builtin-gl-sample-mask on VI.
This is a candidate for stable branches.
v2: the test was simplified by Tom Stellard
llvm-svn: 240824
|
| |
|
|
| |
llvm-svn: 240112
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
TargetInstrInfo::getLdStBaseRegImmOfs to
TargetInstrInfo::getMemOpBaseRegImmOfs and implement for x86. The
implementation only handles a few easy cases now and will be made more
sophisticated in the future.
This is NFCI: the only user of `getLdStBaseRegImmOfs` (now
`getmemOpBaseRegImmOfs`) is `LoadClusterMotion` and `LoadClusterMotion`
is disabled for x86.
Reviewers: reames, ab, MatzeB, atrick
Reviewed By: MatzeB, atrick
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10199
llvm-svn: 239741
|
| |
|
|
| |
llvm-svn: 239657
|
| |
|
|
|
|
| |
This reverts commit 4ea70107c5e51230e9e60f0bf58a0f74aa4885ea.
llvm-svn: 160303
|
|
|
llvm-svn: 160270
|