Remove unused MachineInstr constructors that don't take a DebugLoc argument.

llvm-svn: 165382

Fix PR11985

- BlockAddress has no support of BA + offset form and there is no way to
propagate that offset into machine operand;
- Add BA + offset support and a new interface 'getTargetBlockAd

Fix PR11985

- BlockAddress has no support of BA + offset form and there is no way to
propagate that offset into machine operand;
- Add BA + offset support and a new interface 'getTargetBlockAddress' to
simplify target block address forming;
- All targets are modified to use new interface and X86 backend is enhanced to
support BA + offset addressing.

llvm-svn: 163743

show more ...

Release build: guard dump functions with
"#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)"

No functional change. Update r163339.

llvm-svn: 163653

Release build: guard dump functions with "ifndef NDEBUG"

No functional change.

llvm-svn: 163339

Cleanup a few magic numbers.

llvm-svn: 163263

[ms-inline asm] We only need one bit to represent the AsmDialect in the
MachineInstr.

llvm-svn: 163257

[ms-inline asm] Propagate the asm dialect into the MachineInstr representation.

llvm-svn: 163243

Typo.

llvm-svn: 163154

Actually use the MachineOperand field for isRegTiedToDefOperand().

The MachineOperand::TiedTo field was maintained, but not used.

This patch enables it in isRegTiedToDefOperand() and
isRegTiedToUse

Actually use the MachineOperand field for isRegTiedToDefOperand().

The MachineOperand::TiedTo field was maintained, but not used.

This patch enables it in isRegTiedToDefOperand() and
isRegTiedToUseOperand() which are the actual functions use by the
register allocator.

llvm-svn: 163153

show more ...

Allow tied uses and defs in different orders.

After much agonizing, use a full 4 bits of precious MachineOperand space
to encode this. This uses existing padding, and doesn't grow
MachineOperand bey

Allow tied uses and defs in different orders.

After much agonizing, use a full 4 bits of precious MachineOperand space
to encode this. This uses existing padding, and doesn't grow
MachineOperand beyond its current 32 bytes.

This allows tied defs among the first 15 operands on a normal
instruction, just like the current MCInstrDesc constraint encoding.
Inline assembly needs to be able to tie more than the first 15 operands,
and gets special treatment.

Tied uses can appear beyond 15 operands, as long as they are tied to a
def that's in range.

llvm-svn: 163151

show more ...

Add MachineInstr::tieOperands, remove setIsTied().

Manage tied operands entirely internally to MachineInstr. This makes it
possible to change the representation of tied operands, as I will do
shortl

Add MachineInstr::tieOperands, remove setIsTied().

Manage tied operands entirely internally to MachineInstr. This makes it
possible to change the representation of tied operands, as I will do
shortly.

The constraint that tied uses and defs must be in the same order was too
restrictive.

llvm-svn: 163021

show more ...

Don't use MCInstrDesc flags for implicit operands.

When a MachineInstr is constructed, its implicit operands are added
first, then the explicit operands are inserted before the implicits.

MCInstrDe

Don't use MCInstrDesc flags for implicit operands.

When a MachineInstr is constructed, its implicit operands are added
first, then the explicit operands are inserted before the implicits.

MCInstrDesc has oprand flags like early clobber and operand ties that
apply to the explicit operands.

Don't look at those flags when the implicit operands are first added in
the explicit operands's positions.

llvm-svn: 162910

show more ...

Rename hasVolatileMemoryRef() to hasOrderedMemoryRef().

Ordered memory operations are more constrained than volatile loads and
stores because they must be ordered with respect to all other memory
op

Rename hasVolatileMemoryRef() to hasOrderedMemoryRef().

Ordered memory operations are more constrained than volatile loads and
stores because they must be ordered with respect to all other memory
operations.

llvm-svn: 162861

show more ...

Don't move normal loads across volatile/atomic loads.

It is technically allowed to move a normal load across a volatile load,
but probably not a good idea.

It is not allowed to move a load across a

Don't move normal loads across volatile/atomic loads.

It is technically allowed to move a normal load across a volatile load,
but probably not a good idea.

It is not allowed to move a load across an atomic load with
Ordering > Monotonic, and we model those with MOVolatile as well.

I recently removed the mayStore flag from atomic load instructions, so
they don't need a pseudo-opcode. This patch makes up for the difference.

llvm-svn: 162857

show more ...

Maintain a vaild isTied bit as operands are added and removed.

The isTied bit is set automatically when a tied use is added and
MCInstrDesc indicates a tied operand. The tie is broken when one of th

Maintain a vaild isTied bit as operands are added and removed.

The isTied bit is set automatically when a tied use is added and
MCInstrDesc indicates a tied operand. The tie is broken when one of the
tied operands is removed.

llvm-svn: 162814

show more ...

Add a MachineOperand::isTied() flag.

While in SSA form, a MachineInstr can have pairs of tied defs and uses.
The tied operands are used to represent read-modify-write operands that
must be assigned

Add a MachineOperand::isTied() flag.

While in SSA form, a MachineInstr can have pairs of tied defs and uses.
The tied operands are used to represent read-modify-write operands that
must be assigned the same physical register.

Previously, tied operand pairs were computed from fixed MCInstrDesc
fields, or by using black magic on inline assembly instructions.

The isTied flag makes it possible to add tied operands to any
instruction while getting rid of (some of) the inlineasm magic.

Tied operands on normal instructions are needed to represent predicated
individual instructions in SSA form. An extra <tied,imp-use> operand is
required to represent the output value when the instruction predicate is
false.

Adding a predicate to:

%vreg0<def> = ADD %vreg1, %vreg2

Will look like:

%vreg0<tied,def> = ADD %vreg1, %vreg2, pred:3, %vreg7<tied,imp-use>

The virtual register %vreg7 is the value given to %vreg0 when the
predicate is false. It will be assigned the same physreg as %vreg0.

This commit adds the isTied flag and sets it based on MCInstrDesc when
building an instruction. The flag is not used for anything yet.

llvm-svn: 162774

show more ...

Don't allow TargetFlags on MO_Register MachineOperands.

Register operands are manipulated by a lot of target-independent code,
and it is not always possible to preserve target flags. That means it i

Don't allow TargetFlags on MO_Register MachineOperands.

Register operands are manipulated by a lot of target-independent code,
and it is not always possible to preserve target flags. That means it is
not safe to use target flags on register operands.

None of the targets in the tree are using register operand target flags.
External targets should be using immediate operands to annotate
instructions with operand modifiers.

llvm-svn: 162770

show more ...

Also update MRI use lists when changing a use to a def and vice versa.

This was the cause of the buildbot failures.

llvm-svn: 161643

Move use list management into MachineRegisterInfo.

Register MachineOperands are kept in linked lists accessible via MRI's
reg_iterator interfaces. The linked list management was handled partly
by Ma

Move use list management into MachineRegisterInfo.

Register MachineOperands are kept in linked lists accessible via MRI's
reg_iterator interfaces. The linked list management was handled partly
by MachineOperand methods, partly by MRI methods.

Move all of the list management into MRI, delete
MO::AddRegOperandToRegInfo() and MO::RemoveRegOperandFromRegInfo().

Be more explicit about handling the cases where an MRI pointer isn't
available.

llvm-svn: 161632

show more ...

Add a new kind of MachineOperand: MO_TargetIndex.

A target index operand looks a lot like a constant pool reference, but
it is completely target-defined. It contains the 8-bit TargetFlags, a
32-bit

Add a new kind of MachineOperand: MO_TargetIndex.

A target index operand looks a lot like a constant pool reference, but
it is completely target-defined. It contains the 8-bit TargetFlags, a
32-bit index, and a 64-bit offset. It is preserved by all code generator
passes.

TargetIndex operands can be used to carry target-specific information in
cases where immediate operands won't suffice.

llvm-svn: 161441

show more ...

Finish fixing the MachineOperand hashing, providing a nice modern
hash_value overload for MachineOperands. This addresses a FIXME
sufficient for me to remove it, and cleans up the code nicely too.

T

Finish fixing the MachineOperand hashing, providing a nice modern
hash_value overload for MachineOperands. This addresses a FIXME
sufficient for me to remove it, and cleans up the code nicely too.

The important changes to the hashing logic:
- TargetFlags are now included in all of the hashes. These were complete
missed.
- Register operands have their subregisters and whether they are a def
included in the hash.
- We now actually hash all of the operand types. Previously, many
operand types were simply *dropped on the floor*. For example:
- Floating point immediates
- Large integer immediates (>64-bit)
- External globals!
- Register masks
- Metadata operands
- It removes the offset from the block-address hash; I'm a bit
suspicious of this, but isIdenticalTo doesn't consider the offset for
black addresses.

Any patterns involving these entities could have triggered extreme
slowdowns in MachineCSE or PHIElimination. Let me know if there are PRs
you think might be closed now... I'm looking myself, but I may miss
them.

llvm-svn: 159743

show more ...

The hash function for MI expressions, used by MachineCSE, is really
broken. This patch fixes the superficial problems which lead to the
intractably slow compile times reported in PR13225.

The specif

The hash function for MI expressions, used by MachineCSE, is really
broken. This patch fixes the superficial problems which lead to the
intractably slow compile times reported in PR13225.

The specific issue is that we were failing to include the *offset* of
a global variable in the hash code. Oops. This would in turn cause all
MIs which were only distinguishable due to operating on different
offsets of a global variable to produce identical hash functions. In
some of the test cases attached to the PR I saw hash table activity
where there were O(1000) probes-per-lookup *on average*. A very few
entries were responsible for most of these probes.

There is still quite a bit more to do here. The ad-hoc layering of data
in MachineOperands makes them *extremely* brittle to hash correctly.
We're missing quite a few other cases, the only ones I've fixed here are
the specific MO types which were allowed through the assert() in
getOffset().

llvm-svn: 159741

show more ...

Allow trailing physreg RegisterSDNode operands on non-variadic instructions.

Also allow trailing register mask operands on non-variadic both
MachineSDNodes and MachineInstrs.

The extra physreg Regi

Allow trailing physreg RegisterSDNode operands on non-variadic instructions.

Also allow trailing register mask operands on non-variadic both
MachineSDNodes and MachineInstrs.

The extra physreg RegisterSDNode operands are added to the MI as
<imp-use> operands. This makes it possible to have non-variadic call
instructions.

Call and return instructions really are non-variadic, the argument
registers should only be used implicitly - they are not part of the
encoding.

llvm-svn: 159727

show more ...

Move lib/Analysis/DebugInfo.cpp to lib/VMCore/DebugInfo.cpp and
include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h.

The reasoning is because the DebugInfo module is simply an interface to

Move lib/Analysis/DebugInfo.cpp to lib/VMCore/DebugInfo.cpp and
include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h.

The reasoning is because the DebugInfo module is simply an interface to the
debug info MDNodes and has nothing to do with analysis.

llvm-svn: 159312

show more ...

MachineInstr::eraseFromParent fix for removing bundled instrs.

Patch by Ivan Llopard.

llvm-svn: 158025