This is still a work in progress.

Out-of-order CPUs usually execute instructions from multiple basic
blocks simultaneously, so it is necessary to look at longer traces when
estimating the performance effects of code transformations.

The MachineTraceMetrics analysis will pick a typical trace through a
given basic block and provide performance metrics for the trace. Metrics
will include:

- Instruction count through the trace.
- Issue count per functional unit.
- Critical path length, and per-instruction 'slack'.

These metrics can be used to determine the performance limiting factor
when executing the trace, and how it will be affected by a code
transformation.

Initially, this will be used by the early if-conversion pass.

llvm-svn: 160796

llvm-svn: 160791

Thanks Eli for noticing.

llvm-svn: 160787

is a temporary measure until my fix for PR13021 is ready.

llvm-svn: 160778

llvm-svn: 160775

Patch by Reed Kotler.

llvm-svn: 160774

encounter an invoke of an allocation function. This should fix the dragonegg
bootstrap. Testcase to follow, later.

llvm-svn: 160757

Beckham <verena@codeplay.com>.  Reviewed by Jim Grosbach.

llvm-svn: 160753

original commit msg:
MemoryBuiltins: add support to determine the size of strdup'ed non-constant strings

llvm-svn: 160751

It is redundant; RegisterCoalescer will do the remat if it can't eliminate
the copy. Collected instruction counts before and after this. A few extra
instructions are generated due to spilling but it is normal to see these kinds
of changes with almost any small codegen change, according to Jakob.

This also fixed rdar://11830760 where xor is expected instead of movi0.

llvm-svn: 160749

Report/patch inspiration by Olaf Krzikalla.

llvm-svn: 160744

llvm-svn: 160742

llvm-svn: 160741

When a live range splits into multiple connected components, we would
arbitrarily assign <undef> uses to component 0. This is wrong when the
use is tied to a def that gets assigned to a different component:

  %vreg69<def> = ADD8ri %vreg68<undef>, 1

The use and def must get the same virtual register.

Fix this by assigning <undef> uses to the same component as the value
defined by the instruction, if any:

  %vreg69<def> = ADD8ri %vreg69<undef>, 1

This fixes PR13402. The PR has a test case which I am not including
because it is unlikely to keep exposing this behavior in the future.

llvm-svn: 160739

Before accessing a node as a ConstandSDNode, make sure it actually is one.
No testcase of non-trivial size.

rdar://11948669

llvm-svn: 160735

Include <undef> operands and virtual registers after leaving SSA form.

llvm-svn: 160734

make all Emit*() functions consult the TargetLibraryInfo information before creating a call to a library function.
Update all clients to pass the TLI information around.
Previous draft reviewed by Eli.

llvm-svn: 160733

llvm-svn: 160731

to pop.

llvm-svn: 160725

change.

llvm-svn: 160724

of an array element (rather than at the beginning of the element) and extended
into the next element, then the load from the second element was being handled
wrong due to incorrect updating of the notion of which byte to load next.  This
fixes PR13442.  Thanks to Chris Smowton for reporting the problem, analyzing it
and providing a fix.

llvm-svn: 160711

 
The long branch pass (fixed in r160601) no longer uses the global base register
to compute addresses of branch destinations, so it is not necessary to reserve
a slot on the stack.

llvm-svn: 160703

if Condition Is Met instuctions that was not correctly determining the target
instruction.

So for a jne rel32 instruction:

% cat x.s
.byte 0x0f, 0x85, 0x09, 0x00, 0x00, 0x00
% as x.s

it was incorrectly deterining the target:

% otool -q -tv a.out 
a.out:
(__TEXT,__text) section
0000000000000000	jne	0xd

and with the fix it gets this correct as:

% otool -q -tv a.out
a.out:
(__TEXT,__text) section
0000000000000000	jne	0xf

rdar://11505997

llvm-svn: 160694

Darwin bootstrap. Testcase exists but isn't fully reduced, I expect to commit
the testcase this evening.

llvm-svn: 160693

fputc, memchr, memcmp, putchar, puts, strchr, strncmp

llvm-svn: 160690

are targeting an ELF platform.  Only fold gs-relative (and fs-relative) loads
if it is actually sensible to do so for the target platform.

This fixes PR13438.

llvm-svn: 160687

llvm-svn: 160678

llvm-svn: 160676

llvm-svn: 160668

might be deliberate "one time" leaks, so that leak checkers can find them.
This is a reapply of r160602 with the fix that this time I'm committing the
code I thought I was committing last time; the I->eraseFromParent() goes
*after* the break out of the loop.

llvm-svn: 160664

Change llvm_unreachable in SplitVectorOperand to report_fatal_error. Keeps release builds from crashing if code uses an intrinsic with an illegal type.

llvm-svn: 160661

ExecutionEngine/test-fp.ll.
 
Patch by Petar Jovanovic.

llvm-svn: 160653

Hello world will compile and execute with this patch.

Patch by Reed Kotler.

llvm-svn: 160651

llvm-svn: 160643

rdar://11931823.

llvm-svn: 160637

llvm-svn: 160636

llvm-svn: 160632

llvm-svn: 160631

llvm-svn: 160629

llvm-svn: 160621