passes to a create-pass function instead of a direct constructor call.

llvm-svn: 171622

interfaces which could be extracted from it, and must be provided on
construction, to a chained analysis group.

The end goal here is that TTI works much like AA -- there is a baseline
"no-op" and target independent pass which is in the group, and each
target can expose a target-specific pass in the group. These passes will
naturally chain allowing each target-specific pass to delegate to the
generic pass as needed.

In particular, this will allow a much simpler interface for passes that
would like to use TTI -- they can have a hard dependency on TTI and it
will just be satisfied by the stub implementation when that is all that
is available.

This patch is a WIP however. In particular, the "stub" pass is actually
the one and only pass, and everything there is implemented by delegating
to the target-provided interfaces. As a consequence the tools still have
to explicitly construct the pass. Switching targets to provide custom
passes and sinking the stub behavior into the NoTTI pass is the next
step.

llvm-svn: 171621

llvm-svn: 171620

llvm-svn: 171619

interface.

llvm-svn: 171618

the ScalarTargetTransformInfo interface.

llvm-svn: 171617

interface rather than the ScalarTargetTransformInterface.

llvm-svn: 171616

VectorTargetTransformInfo into the TargetTransformInfo pass,
implementing them be delegating back out to the two subobjects.

This is the first step to folding the interfaces together and making
TargetTransformInfo a normal analysis pass (specifically an analysis
group which targets can provide target-specific analysis pass
implementations of).

No callers are migrated here, this just stubs out the interface. Next
step will be to migrate all the callers to directly operate on TTI
instead of STTI or VTTI respectively. That will allow replacing the
machinery for delivering TTI without changing every caller at once.

WIP, I promise all the duplicated interfaces will be removed in the end,
this just decouples the steps of the process.

llvm-svn: 171615

values -- that's not required to fix the bug that was cropping up, and
the values selected made the enumeration's underlying type signed and
introduced some warnings. This fixes the -Werror build.

The underlying issue here was that the DenseMapInfo was casting values
completely outside the range of the underlying storage of the
enumeration to the enumeration's type. GCC went and "optimized" that
into infloops and other misbehavior. By providing designated special
values for these keys in the dense map, we ensure they are indeed
representable and that they won't be used for anything else.

It might be better to reuse None for the empty key and have the
tombstone share the value of the sentinel enumerator, but honestly
having 2 extra enumerators seemed not to matter and this seems a bit
simpler. I'll let Bill shuffle this around (or ask me to shuffle it
around) if he prefers it to look a different way.

I also made the switch a bit more clear (and produce a better assert)
that the enumerators are *never* going to show up and are errors if they
do.

llvm-svn: 171614

unused, there were transitive includes needed.

llvm-svn: 171613

llvm-svn: 171612

IR/Attributes: Provide EmptyKey and TombstoneKey in part of enum, as workaround for gcc-4.4 take #2.

I will investigate, later, what was wrong. I am too tired for now.

llvm-svn: 171611

This change essentially reverts r87069 which came without a test case. It
causes no regressions in the GDB 7.5 test suite & fixes 25 xfails (commit
to the test suite to follow). If anyone can present a test case that
demonstrates why this check is necessary I'd be happy to account for it in one
way or another.

llvm-svn: 171609

Recommit r171461 which was incorrectly reverted. Mark DIV/IDIV instructions hasSideEffects=1 because they can trap when dividing by 0. This is needed to keep early if conversion from moving them across basic blocks.

llvm-svn: 171608

Turns out that the ExecPath for the ObjC migrator would also get set.

Fixes <rdar://problem/12961769>.

llvm-svn: 171607

Add unconditional logging messages to every place in debugserver
where we send a SIGKILL signal or do a ptrace PT_KILL call to
terminate the inferior process.  When the debuggee is silently
killed off, the console logging from debugserver can disambiguate
whether debugserver killed off the process because it failed to
completely set it up, becuase it was told to (via the "k" packet),
or if some external daemon killed it.

llvm-svn: 171606

LLVM ignores this data for now - patch for that to follow.

llvm-svn: 171605

Referring back to the original commit (r115090) which was a frontend only test
I adjusted this test to verify the frontend change that was made, to emit the
protected access value in the flags metadata field.

llvm-svn: 171604

URL: http://llvm.org/viewvc/llvm-project?rev=171524&view=rev
Log:
The current Intel Atom microarchitecture has a feature whereby when a function
returns early then it is slightly faster to execute a sequence of NOP
instructions to wait until the return address is ready,
as opposed to simply stalling on the ret instruction
until the return address is ready.

When compiling for X86 Atom only, this patch will run a pass, called
"X86PadShortFunction" which will add NOP instructions where less than four
cycles elapse between function entry and return.

It includes tests.

Patch by Andy Zhang.

llvm-svn: 171603

llvm-svn: 171602

llvm-svn: 171601

With DenseMapInfo<Enum>, it is miscompiled on g++-4.4.

    static inline Enum getEmptyKey() { return Enum(<arbitrary int/unsigned value>); }

    isEauql(getEmptyKey(), ...)

The compiler mis-assumes the return value is not aliased to Enum.

llvm-svn: 171600

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

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

This function works like memmove() for MachineOperands, except it also
updates any use-def chains containing the moved operands.

The use-def chains are updated without affecting the order of operands
in the list. That isn't possible when using the
removeRegOperandFromUseList() and addRegOperandToUseList() functions.

Callers to follow soon.

llvm-svn: 171597

[CMake] Don't add flags this late and don't force libc++. Error if we know the compiler doesn't support c++11.

llvm-svn: 171596

legality of an address mode to not use a struct of four values and
instead to accept them as parameters. I'd love to have named parameters
here as most callers only care about one or two of these, but the
defaults aren't terribly scary to write out.

That said, there is no real impact of this as the passes aren't yet
using STTI for this and are still relying upon TargetLowering.

llvm-svn: 171595

Move common header files into a 'support' directory; make 'testit' include -I to that directory; rename 'iterators.h' to 'iterator_test.h'; remove hard-coded paths to include files from more than 350 source files

llvm-svn: 171594

RecusiveASTVisitor. With Clang and modern GCCs this was found through
the injected class name of the base class but older GCCs don't properly
implement the injected class name rules.

llvm-svn: 171593

and adds a new file ReaderWriterYAML.cpp that uses YAML I/O.

Lots of tweaks to test suite for slightly different YAML encoding.

llvm-svn: 171592

llvm-svn: 171591

next to its only user. This helper relies on TargetLowering information
that shouldn't be generally used throughout the Transfoms library, and
so it made little sense as a generic utility.

This also consolidates the file where we need to remove the remaining
uses of TargetLowering in favor of the IR-layer abstract interface in
TargetTransformInfo.

llvm-svn: 171590

Fixes the CMake build. It took me cutting and pasting this before
I managed to see the missing character. =]

llvm-svn: 171589

and add stack alignment information.

llvm-svn: 171588

and add stack alignment information.

llvm-svn: 171587

The Attribute class is eventually going to represent one attribute. So we need
this class to create the set of attributes. Add some iterator methods to the
builder to access its internal bits in a nice way.

llvm-svn: 171586

It is somewhat hard to test linkage, so I decided to try to add an assert. This
already found some interesting cases where there were different.

llvm-svn: 171585

llvm-svn: 171584

iLoopVectorize: Non commutative operators can be used as reduction variables as long as the reduction chain is used in the LHS.

PR14803.

llvm-svn: 171583

This should fix clang-native-arm-cortex-a9. Thanks Renato.

llvm-svn: 171582