For inline asm:

- recognize string "{memory}" in the MI generation
- mark as mayload/maystore when there's a memory clobber constraint.

PR14859.

Patch by Krzysztof Parzyszek

llvm-svn: 172228

Allow hasProperty() to be called on bundle-internal instructions.

When calling hasProperty() on an instruction inside a bundle, it should
always behave as if IgnoreBundle was passed, and just return

Allow hasProperty() to be called on bundle-internal instructions.

When calling hasProperty() on an instruction inside a bundle, it should
always behave as if IgnoreBundle was passed, and just return properties
for the current instruction.

Only attempt to aggregate bundle properties whan asked about the bundle
header.

The assertion fires on existing ARM test cases without this fix.

llvm-svn: 172082

show more ...

Support headerless bundles in MachineInstr::hasProperty().

This function can still work without a BUNDLE header instruction.

llvm-svn: 172029

Don't print bundle flags.

The bundle flags are used by MachineBasicBlock::print(), they don't need
to clutter up individual MachineInstrs.

llvm-svn: 171986

Don't require BUNDLE headers in MachineInstr::getBundleSize().

It is possible to build MI bundles that don't begin with a BUNDLE
header. Add support for such bundles, counting all instructions insid

Don't require BUNDLE headers in MachineInstr::getBundleSize().

It is possible to build MI bundles that don't begin with a BUNDLE
header. Add support for such bundles, counting all instructions inside
the bundle.

llvm-svn: 171985

show more ...

Fix a typo in MachineInstr::unbundleFromSucc() method.

llvm-svn: 171983

Pack MachineOperand bitfields better.

Previously, 4 bits were unused.

llvm-svn: 171814

Pack MachineInstr fields better.

This shrinks MachineInstr to 64 bytes (from 72).

llvm-svn: 171813

Don't call destructors on MachineInstr and MachineOperand.

The series of patches leading up to this one makes llc -O0 run 8% faster.

When deallocating a MachineFunction, there is no need to visit a

Don't call destructors on MachineInstr and MachineOperand.

The series of patches leading up to this one makes llc -O0 run 8% faster.

When deallocating a MachineFunction, there is no need to visit all
MachineInstr and MachineOperand objects to deallocate them. All their
memory come from a BumpPtrAllocator that is about to be purged, and they
have empty destructors anyway.

This only applies when deallocating the MachineFunction.
DeleteMachineInstr() should still be used to recycle MI memory during
the codegen passes.

Remove the LeakDetector support for MachineInstr. I've never seen it
used before, and now it definitely doesn't work. With this patch, leaked
MachineInstrs would be much less of a problem since all of their memory
will be reclaimed by ~MachineFunction().

llvm-svn: 171599

show more ...

Use ArrayRecycler for MachineInstr operand lists.

Instead of an std::vector<MachineOperand>, use MachineOperand arrays
from an ArrayRecycler living in MachineFunction.

This has several advantages:

Use ArrayRecycler for MachineInstr operand lists.

Instead of an std::vector<MachineOperand>, use MachineOperand arrays
from an ArrayRecycler living in MachineFunction.

This has several advantages:

- MachineInstr now has a trivial destructor, making it possible to
delete them in batches when destroying MachineFunction. This will be
enabled in a later patch.

- Bypassing malloc() and free() can be faster, depending on the system
library.

- MachineInstr objects and their operands are allocated from the same
BumpPtrAllocator, so they will usually be next to each other in
memory, providing better locality of reference.

- Reduce MachineInstr footprint. A std::vector is 24 bytes, the new
operand array representation only uses 8+4+1 bytes in MachineInstr.

- Better control over operand array reallocations. In the old
representation, the use-def chains would be reordered whenever a
std::vector reached its capacity. The new implementation never changes
the use-def chain order.

Note that some decisions in the code generator depend on the use-def
chain orders, so this patch may cause different assembly to be produced
in a few cases.

llvm-svn: 171598

show more ...

Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long

Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366

show more ...

Remove a special case that doesn't seem necessary any longer.

Back when this exception was added, it was skipping a lot more code, but
now it just looks like a premature optimization.

llvm-svn: 170

Remove a special case that doesn't seem necessary any longer.

Back when this exception was added, it was skipping a lot more code, but
now it just looks like a premature optimization.

llvm-svn: 170989

show more ...

Use getNumOperands() instead of Operands.size().

The representation of the Operands array is going to change soon so it
can be allocated from a BumpPtrAllocator.

llvm-svn: 170988

Require the two-argument MI::addOperand(MF, MO) for dangling instructions.

Instructions that are inserted in a basic block can still be decorated
with addOperand(MO).

Make the two-argument addOpera

Require the two-argument MI::addOperand(MF, MO) for dangling instructions.

Instructions that are inserted in a basic block can still be decorated
with addOperand(MO).

Make the two-argument addOperand() function contain the actual
implementation. This function will now always have a valid MF reference
that it can use for memory allocation.

llvm-svn: 170798

show more ...

Add an MF argument to MI::copyImplicitOps().

This function is often used to decorate dangling instructions, so a
context reference is required to allocate memory for the operands.

Also add a corres

Add an MF argument to MI::copyImplicitOps().

This function is often used to decorate dangling instructions, so a
context reference is required to allocate memory for the operands.

Also add a corresponding MachineInstrBuilder method.

llvm-svn: 170797

show more ...

Use two-arg addOperand(MF, MO) internally in MachineInstr when possible.

llvm-svn: 170796

Remove two dead functions.

llvm-svn: 170766

Use bidirectional bundle flags to simplify important functions.

The bundle_iterator::operator++ function now doesn't need to dig out the
basic block and check against end(). It can use the isBundled

Use bidirectional bundle flags to simplify important functions.

The bundle_iterator::operator++ function now doesn't need to dig out the
basic block and check against end(). It can use the isBundledWithSucc()
flag to find the last bundled instruction safely.

Similarly, MachineInstr::isBundled() no longer needs to look at
iterators etc. It only has to look at flags.

llvm-svn: 170473

show more ...

Verify bundle flag consistency when setting them.

Now that the bundle flag aware APIs are all in place, it is possible to
continuously verify the flag consistency.

llvm-svn: 170465

Don't allow the automatically updated MI flags to be set directly.

The bundle-related MI flags need to be kept in sync with the neighboring
instructions. Don't allow the bulk flag-setting setFlags()

Don't allow the automatically updated MI flags to be set directly.

The bundle-related MI flags need to be kept in sync with the neighboring
instructions. Don't allow the bulk flag-setting setFlags() function to
change them.

Also don't copy MI flags when cloning an instruction. The clone's bundle
flags will be set when it is explicitly inserted into a bundle.

llvm-svn: 170459

show more ...

Tighten up the erase/remove API for bundled instructions.

Most code is oblivious to bundles and uses the MBB::iterator which only
visits whole bundles. MBB::erase() operates on whole bundles at a ti

Tighten up the erase/remove API for bundled instructions.

Most code is oblivious to bundles and uses the MBB::iterator which only
visits whole bundles. MBB::erase() operates on whole bundles at a time
as before.

MBB::remove() now refuses to remove bundled instructions. It is not safe
to remove all instructions in a bundle without deleting them since there
is no way of returning pointers to all the removed instructions.

MBB::remove_instr() and MBB::erase_instr() will now update bundle flags
correctly, lifting individual instructions out of bundles while leaving
the remaining bundle intact.

The MachineInstr convenience functions are updated so

eraseFromParent() erases a whole bundle as before
eraseFromBundle() erases a single instruction, leaving the rest of its bundle.
removeFromParent() refuses to operate on bundled instructions, and
removeFromBundle() lifts a single instruction out of its bundle.

These functions will no longer accidentally split or coalesce bundles -
bundle flags are updated to preserve the existing bundling, and explicit
bundleWith* / unbundleFrom* functions should be used to change the
instruction bundling.

This API update is still a work in progress. I am going to update APIs
first so they maintain bundle flags automatically when possible. Then
I'll add stricter verification of the bundle flags.

llvm-svn: 170384

show more ...

Add higher-level API for dealing with bundled MachineInstrs.

This is still a work in progress. The purpose is to make bundling and
unbundling operations explicit, and to catch errors where bundles a

Add higher-level API for dealing with bundled MachineInstrs.

This is still a work in progress. The purpose is to make bundling and
unbundling operations explicit, and to catch errors where bundles are
broken or created inadvertently.

The old IsInsideBundle flag is replaced by two MI flags: BundledPred
which has the same meaning as IsInsideBundle, and BundledSucc which is
set on instructions that are bundled with a successor. Having two flags
provdes redundancy to detect when a bundle is inadvertently torn by a
splice() or insert(), and it makes it possible to write bundle iterators
that don't need to peek at adjacent instructions.

The new flags can't be manipulated directly (once setIsInsideBundle is
gone). Instead there are MI functions to make and break bundle bonds.

The setIsInsideBundle function will be removed in a future commit. It
should be replaced by bundleWithPred().

llvm-svn: 169583

show more ...

Remove unused MachineInstr constructors.

A MachineInstr can only ever be constructed by CreateMachineInstr() and
CloneMachineInstr(), and those factories don't use the removed
constructors.

llvm-sv

Remove unused MachineInstr constructors.

A MachineInstr can only ever be constructed by CreateMachineInstr() and
CloneMachineInstr(), and those factories don't use the removed
constructors.

llvm-svn: 169395

show more ...

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

show more ...

Check that iterator I is not the end iterator.

llvm-svn: 167086