| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
sink them into MC layer.
- Added MCInstrInfo, which captures the tablegen generated static data. Chang
TargetInstrInfo so it's based off MCInstrInfo.
llvm-svn: 134021
|
|
|
|
| |
llvm-svn: 133944
|
|
|
|
|
|
| |
No functional change.
llvm-svn: 132455
|
|
|
|
|
|
|
|
| |
on CodeGen/X86/2007-05-07-InvokeSRet.ll. There is probably a bug here that was
fixed by r128961, but since there is no test or reference to a source file I have
to revert it.
llvm-svn: 131618
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
landing pad as its successor.
SjLj exception handling jumps to the correct landing pad via a switch statement
that's generated right before code-gen. Loosen the constraint in the machine
instruction verifier to allow for this. Note, this isn't the most rigorous check
since we cannot determine where that switch statement came from. But it's
marginally better than turning this check off when SjLj exceptions are used.
<rdar://problem/9187612>
llvm-svn: 130881
|
|
|
|
|
|
| |
Treat the landing pad as a normal successor when that happens.
llvm-svn: 128961
|
|
|
|
| |
llvm-svn: 128643
|
|
|
|
|
|
|
|
|
|
|
|
| |
This way, shrinkToUses() will ignore the instruction that is about to be
deleted, and we avoid leaving invalid live ranges that SplitKit doesn't like.
Fix a misunderstanding in MachineVerifier about <def,undef> operands. The
<undef> flag is valid on def operands where it has the same meaning as <undef>
on a use operand. It only applies to sub-register defines which also read the
full register.
llvm-svn: 128642
|
|
|
|
|
|
|
|
|
|
| |
Allow a live range to end with a kill flag, but don't allow a kill flag that
doesn't end the live range.
This makes the machine code verifier more useful during register allocation when
kill flag computation is deferred.
llvm-svn: 124838
|
|
|
|
|
|
| |
The slot indexes must be monotonically increasing through the function.
llvm-svn: 123324
|
|
|
|
| |
llvm-svn: 123322
|
|
|
|
|
|
|
|
|
|
| |
without a TRI instance.
Print virtual registers numbered from 0 instead of the arbitrary
FirstVirtualRegister. The first virtual register is printed as %vreg0.
TRI::NoRegister is printed as %noreg.
llvm-svn: 123107
|
|
|
|
|
|
| |
virtual registers.
llvm-svn: 123100
|
|
|
|
|
|
| |
in the most obvious way.
llvm-svn: 122610
|
|
|
|
|
|
|
|
|
| |
valno verification. The "Different value live out of predecessor" check is
incorrect in the case of phi-def valnos, so just skip that check for phi-def
valnos and instead check that all of the valnos for predecessors have phi-kill.
Fixes PR8863.
llvm-svn: 122581
|
|
|
|
|
|
| |
out-edges. Fixes PR8824.
llvm-svn: 122228
|
|
|
|
|
|
| |
begin at DEF slots. Fixes the second half of PR8813.
llvm-svn: 122225
|
|
|
|
| |
llvm-svn: 122224
|
|
|
|
|
|
| |
the register; it may be a dead def instead. Fixes PR8820.
llvm-svn: 122218
|
|
|
|
|
|
| |
PR8822.
llvm-svn: 122207
|
|
|
|
|
|
| |
half of PR8813.
llvm-svn: 122205
|
|
|
|
| |
llvm-svn: 122199
|
|
|
|
|
|
|
|
| |
createMachineVerifierPass and MachineFunction::verify.
The banner is printed before the machine code dump, just like the printer pass.
llvm-svn: 122113
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the operand uses the same register as a tied operand:
%r1 = add %r1, %r1
If add were a three-address instruction, kill flags would be required on at
least one of the uses. Since it is a two-address instruction, the tied use
operand must not have a kill flag.
This change makes the kill flag on the untied use operand optional.
llvm-svn: 122082
|
|
|
|
|
|
| |
operands in a variadic instruction.
llvm-svn: 119446
|
|
|
|
|
|
| |
(and likely) wrong about anyhow.
llvm-svn: 119320
|
|
|
|
|
|
|
| |
It is legal for an instruction to have two operands using the same register,
only one a kill. This is interpreted as a kill.
llvm-svn: 117981
|
|
|
|
|
|
|
|
| |
At least X86FloatingPoint requires correct kill flags after register allocation,
and targets using register scavenging benefit. Conservative kill flags are not
enough.
llvm-svn: 117960
|
|
|
|
|
|
|
| |
When an instruction refers to a spill slot with a LiveStacks entry, check that
the spill slot is live at the instruction.
llvm-svn: 117944
|
|
|
|
| |
llvm-svn: 117762
|
|
|
|
|
|
| |
multiplicity.
llvm-svn: 117630
|
|
|
|
| |
llvm-svn: 117602
|
|
|
|
|
|
| |
Only virtuals should be requires to be connected.
llvm-svn: 117422
|
|
|
|
|
|
| |
components, each should get its own virtual register.
llvm-svn: 117407
|
|
|
|
|
|
| |
SlotIndexes when available.
llvm-svn: 117392
|
|
|
|
| |
llvm-svn: 117391
|
|
|
|
|
|
| |
Magic is happening that we don't understand.
llvm-svn: 117370
|
|
|
|
|
|
| |
of all predecessors.
llvm-svn: 117191
|
|
|
|
| |
llvm-svn: 117170
|
|
|
|
|
|
| |
unconditional branch.
llvm-svn: 117041
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
exposes an initializeMyPassFunction(), which
must be called in the pass's constructor. This function uses static dependency declarations to recursively initialize
the pass's dependencies.
Clients that only create passes through the createFooPass() APIs will require no changes. Clients that want to use the
CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h
before parsing commandline arguments.
I have tested this with all standard configurations of clang and llvm-gcc on Darwin. It is possible that there are problems
with the static dependencies that will only be visible with non-standard options. If you encounter any crash in pass
registration/creation, please send the testcase to me directly.
llvm-svn: 116820
|
|
|
|
| |
llvm-svn: 115996
|
|
|
|
| |
llvm-svn: 115874
|
|
|
|
| |
llvm-svn: 115408
|
|
|
|
|
|
| |
passes over to the new registration API.
llvm-svn: 111815
|
|
|
|
| |
llvm-svn: 111540
|
|
|
|
| |
llvm-svn: 110460
|
|
|
|
| |
llvm-svn: 110454
|
|
|
|
|
|
|
|
|
| |
When a physical register is in use, some alias of that register has a live
interval with a relevant live range. That is the sad state of intervals after
physreg coalescing of subregs, and it is good enough for correct register
allocation.
llvm-svn: 110452
|
|
|
|
| |
llvm-svn: 110410
|