| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
| |
Now that MI->getRegClassConstraint() can also handle inline assembly,
don't bail when recomputing the register class of a virtual register
used by inline asm.
This fixes PR11078.
llvm-svn: 141836
|
| |
|
|
|
|
|
|
|
| |
Most instructions have some requirements for their register operands.
Usually, this is expressed as register class constraints in the
MCInstrDesc, but for inline assembly the constraints are encoded in the
flag words.
llvm-svn: 141835
|
| |
|
|
| |
llvm-svn: 141834
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The inline asm operand constraint is initially encoded in the virtual
register for the operand, but that register class may change during
coalescing, and the original constraint is lost.
Encode the original register class as part of the flag word for each
inline asm operand. This makes it possible to recover the actual
constraint required by inline asm, just like we can for normal
instructions.
llvm-svn: 141833
|
| |
|
|
|
|
|
|
|
|
| |
our current machine instruction defines a register with the same register class
as what's being replaced. This showed up in the SPEC 403.gcc benchmark, where it
would ICE because a tail call was expecting one register class but was given
another. (The machine instruction verifier catches this situation.)
<rdar://problem/10270968>
llvm-svn: 141830
|
| |
|
|
|
|
| |
behavior. Based on patch by Ahmed Charles.
llvm-svn: 141829
|
| |
|
|
|
|
| |
to investigate the regressions.
llvm-svn: 141813
|
| |
|
|
|
|
|
|
|
|
|
| |
rather than the previous index. If a block has a single instruction, the
previous index may be in a different basic block.
I have no clue how this used to work on all of test-suite, because now this
failure is seen quite often when trying to compile code with -strong-phi-elim.
This fixes PR10252.
llvm-svn: 141812
|
| |
|
|
|
|
| |
intended, but only by accident.
llvm-svn: 141779
|
| |
|
|
|
|
|
| |
containing loop's header to see if that's a landing pad. If it is, then we don't
want to hoist instructions out of the loop and above the header.
llvm-svn: 141767
|
| |
|
|
| |
llvm-svn: 141763
|
| |
|
|
|
|
|
|
|
| |
1. The speculation check may not have been performed if the BB hasn't had a load
LICM candidate.
2. If the candidate would be CSE'ed, then go ahead and speculatively LICM the
instruction even if it's in high register pressure situation.
llvm-svn: 141747
|
| |
|
|
|
|
| |
Also teach MachineLICM to avoid "speculation" when register pressure is high.
llvm-svn: 141744
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
file. Since it should only be used when necessary propagate it through
the backend code generation and tweak testcases accordingly.
This helps with code like in clang's test/CodeGen/debug-info-line.c where
we have multiple #line directives within a single lexical block and want
to generate only a single block that contains each file change.
Part of rdar://10246360
llvm-svn: 141729
|
| |
|
|
| |
llvm-svn: 141728
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The blocks with invokes have branches to the dispatch block, because that more
correctly models the behavior of the CFG. The dispatch of course has edges to
the landing pads. Those landing pads could contain invokes, which then have
branches back to the dispatch. This creates a loop. The machine LICM pass looks
at this loop and thinks it can hoist elements out of it. But because the
dispatch is an alternate entry point into the program, the hoisted instructions
won't be executed.
I wasn't able to get a testcase which was small and could reproduce all of the
time. The function_try_block.cpp in llvm-test was where this showed up.
llvm-svn: 141726
|
| |
|
|
|
|
|
| |
For example, MachineLICM should not hoist a load that is not guaranteed to be executed.
Radar 10254254.
llvm-svn: 141689
|
| |
|
|
| |
llvm-svn: 141667
|
| |
|
|
|
|
| |
type is illegal (for example, v2i16 on systems where the smallest store size is i32)
llvm-svn: 141661
|
| |
|
|
| |
llvm-svn: 141659
|
| |
|
|
| |
llvm-svn: 141594
|
| |
|
|
|
|
|
|
|
|
|
| |
Allow targets to expand COPY and other standard pseudo-instructions
before they are expanded with copyPhysReg().
This allows the target to examine the COPY instruction for extra
operands indicating it can be widened to a preferable super-register
copy. See the ARM -widen-vmovs option.
llvm-svn: 141578
|
| |
|
|
|
|
| |
instructions.
llvm-svn: 141576
|
| |
|
|
|
|
|
| |
For example, MachineLICM should not hoist a load that is not guaranteed to be executed.
Radar 10254254.
llvm-svn: 141569
|
| |
|
|
|
|
|
|
| |
across unwind edges. This is for the back-end which expects such things.
The code is from the original SjLj EH pass.
llvm-svn: 141463
|
| |
|
|
|
|
| |
do. This will be useful later on with the new SJLJ stuff.
llvm-svn: 141416
|
| |
|
|
|
|
| |
Fixes <rdar://problem/10235725>
llvm-svn: 141357
|
| |
|
|
| |
llvm-svn: 141356
|
| |
|
|
|
|
| |
with this patch.
llvm-svn: 141333
|
| |
|
|
|
|
| |
site.
llvm-svn: 141226
|
| |
|
|
|
|
|
| |
to the landing pad. This will be used by the back-end to generate the jump
tables for dispatching the arriving longjmp in sjlj eh.
llvm-svn: 141224
|
| |
|
|
| |
llvm-svn: 141221
|
| |
|
|
|
|
|
|
|
| |
PhysReg operands are not allowed to have sub-register indices at all.
For virtual registers with sub-reg indices, check that all registers in
the register class support the sub-reg index.
llvm-svn: 141220
|
| |
|
|
| |
llvm-svn: 141218
|
| |
|
|
| |
llvm-svn: 141214
|
| |
|
|
|
|
|
|
|
|
|
|
| |
EXTRACT_SUBREG is emitted as %dst = COPY %src:sub, so there is no need to
constrain the %dst register class. RegisterCoalescer will apply the
necessary constraints if it decides to eliminate the COPY.
The %src register class does need to be constrained to something with
the right sub-registers, though. This is currently done manually with
COPY_TO_REGCLASS nodes. They can possibly be removed after this patch.
llvm-svn: 141207
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The register class created by INSERT_SUBREG and SUBREG_TO_REG must be
legal and support the SubIdx sub-registers.
The new getSubClassWithSubReg() hook can compute that.
This may create INSERT_SUBREG instructions defining a larger register
class than the sub-register being inserted. That is OK,
RegisterCoalescer will constrain the register class as needed when it
eliminates the INSERT_SUBREG instructions.
llvm-svn: 141198
|
| |
|
|
|
|
|
|
| |
TwoAddressInstructionPass should annotate instructions with <undef>
flags when it lower REG_SEQUENCE instructions. LiveIntervals should not
be in the business of modifying code (except for kill flags, perhaps).
llvm-svn: 141187
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For example:
%vreg10:dsub_0<def,undef> = COPY %vreg1
%vreg10:dsub_1<def> = COPY %vreg2
is rewritten as:
%D2<def> = COPY %D0, %Q1<imp-def>
%D3<def> = COPY %D1, %Q1<imp-use,kill>, %Q1<imp-def>
The first COPY doesn't care about the previous value of %Q1, so it
doesn't read that register.
The second COPY is a partial redefinition of %Q1, so it implicitly kills
and redefines that register.
This makes it possible to recognize instructions that can harmlessly
clobber the full super-register. The write and don't read the
super-register.
llvm-svn: 141139
|
| |
|
|
|
|
|
|
| |
RegisterCoalescer can create sub-register defs when it is joining a
register with a sub-register. Add <undef> flags to these new
sub-register defs where appropriate.
llvm-svn: 141138
|
| |
|
|
|
|
| |
modes. These are used by disassemblers to provide better disassembly, particularly on targets like ARM Thumb that like to intermingle data in the TEXT segment.
llvm-svn: 141135
|
| |
|
|
|
|
| |
for later use.
llvm-svn: 141125
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The <undef> flag says that a MachineOperand doesn't read its register,
or doesn't depend on the previous value of its register.
A full register def never depends on the previous register value. A
partial register def may depend on the previous value if it is intended
to update part of a register.
For example:
%vreg10:dsub_0<def,undef> = COPY %vreg1
%vreg10:dsub_1<def> = COPY %vreg2
The first copy instruction defines the full %vreg10 register with the
bits not covered by dsub_0 defined as <undef>. It is not considered a
read of %vreg10.
The second copy modifies part of %vreg10 while preserving the rest. It
has an implicit read of %vreg10.
This patch adds a MachineOperand::readsReg() method to determine if an
operand reads its register.
Previously, this was modelled by adding a full-register <imp-def>
operand to the instruction. This approach makes it possible to
determine directly from a MachineOperand if it reads its register. No
scanning of MI operands is required.
llvm-svn: 141124
|
| |
|
|
| |
llvm-svn: 141050
|
| |
|
|
| |
llvm-svn: 141040
|
| |
|
|
|
|
| |
the need for returning a std::pair.
llvm-svn: 141026
|
| |
|
|
| |
llvm-svn: 141005
|
| |
|
|
| |
llvm-svn: 141004
|
| |
|
|
|
|
| |
of the type. Formatted lines to the 80 char limit.
llvm-svn: 140952
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and the alignment is 0 (i.e., it's defined globally in one file and declared in
another file) it could get an alignment which is larger than the ABI allows for
that type, resulting in aligned moves being used for unaligned loads.
For instance, in file A.c:
struct S s;
In file B.c:
struct {
// something long
};
extern S s;
void foo() {
struct S p = s;
// ...
}
this copy is a 'memcpy' which is turned into a series of 'movaps' instructions
on X86. But this is wrong, because 'struct S' has alignment of 4, not 16.
llvm-svn: 140902
|