the source code should now be set up to handle this.

llvm-svn: 171570

if-ed out code paths and on Windows. Hopefully restores the Windows
build. Thanks to Reid Kleckner for helping triage this.

llvm-svn: 171568

llvm-svn: 171567

defines _POSIX_CPUTIME but doesn't support the clock_* functions.

I don't test the value of _POSIX_CPUTIME because the spec merely says
that if it is defined, the CPU-specific timers are available, whereas it
says that _POSIX_TIMERS must be defined and defined to a value greater
than zero. However, this may not work, as the POSIX spec clearly states:

  "If the symbolic constant _POSIX_CPUTIME is defined, then the symbolic
  constant _POSIX_TIMERS shall also be defined by the implementation to
  have the value 200112L."

If this doesn't work, I'll add more hacks for Darwin.

llvm-svn: 171565

llvm-svn: 171559

The bit mask thing will be a thing of the past. It's not extensible enough. Get
rid of its use here. Opt instead for using a vector to hold the attributes.

Note: Some of this code will become obsolete once the rewrite is further along.
llvm-svn: 171553

wall time, user time, and system time since a process started.

For walltime, we currently use TimeValue's interface and a global
initializer to compute a close approximation of total process runtime.

For user time, this adds support for an somewhat more precise timing
mechanism -- clock_gettime with the CLOCK_PROCESS_CPUTIME_ID clock
selected.

For system time, we have to do a full getrusage call to extract the
system time from the OS. This is expensive but unavoidable.

In passing, clean up the implementation of the old APIs and fix some
latent bugs in the Windows code. This might have manifested on Windows
ARM systems or other systems with strange 64-bit integer behavior.

The old API for this both user time and system time simultaneously from
a single getrusage call. While this results in fewer system calls, it
also results in a lower precision user time and if only user time is
desired, it introduces a higher overhead. It may be worthwhile to switch
some of the pass timers to not track system time and directly track user
and wall time. The old API also tracked walltime in a confusing way --
it just set it to the current walltime rather than providing any measure
of wall time since the process started the way buth user and system time
are tracked. The new API is more consistent here.

The plan is to eventually implement these methods for a *child* process
by using the wait3(2) system call to populate an rusage struct
representing the whole subprocess execution. That way, after waiting on
a child process its stats will become accurate and cheap to query.

llvm-svn: 171551

llvm-svn: 171550

because conditions in the next case prevented from doing anything nasty.

llvm-svn: 171549

A BumpPtrAllocator has an empty Deallocate() method, but
Recycler::clear() would still call it for every single object ever
allocated, bringing all those objects into cache. As a bonus,
iplist::remove() will also write to the Prev/Next pointers on all the
objects, so all those cache lines have to be written back to RAM before
the pages are given back to the OS.

Stop wasting time and memory bandwith by using the new
clearAndLeakUnsafely() function to jettison all the recycled objects.

llvm-svn: 171541

The iplist::clear() function can be quite expensive because it traverses
the entire list, calling deleteNode() and removeNodeFromList() on each
element. If node destruction and deallocation can be handled some other
way, clearAndLeakNodesUnsafely() can be used to jettison all nodes
without bringing them into cache.

The function name is meant to be ominous.

llvm-svn: 171540

The R600 target has test cases that exercises this code.

llvm-svn: 171538

Since subtraction does not commute the loop vectorizer incorrectly vectorizes
reductions such as x = A[i] - x.

Disabling for now.

llvm-svn: 171537

types and a FIXME for what we should be doing. Should solve the
immediacy of PR12069 where our debug info is crashing another
tool.

llvm-svn: 171536

llvm-svn: 171535

Fixed up some DEBUG messages where I was putting in the text of a message the method where it was being called when I should have just prefixed the actual message with Pass::Method.

Additionally I fixed some whitespace issues.

llvm-svn: 171534

llvm-svn: 171525

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: 171524

* Remove dead methods.
* Use the 'operator==' method instead of 'contains', which isn't needed.
* Fix some comments.

No functionality change.

llvm-svn: 171523

[Object][ELF] Add a maximum alignment. This is used by createELFObjectFile to create a properly aligned reader.

llvm-svn: 171520

vectors are being compared.

llvm-svn: 171517

llvm-svn: 171515

Update test case to verify flow sequence is
written as a flow sequence.

llvm-svn: 171514

shift_rotate_imm64.

llvm-svn: 171513

reachablity.

We conservatively approximate the reachability analysis by saying it is not
reachable if there is a single path starting from "From" and the path does not
reach "To".

rdar://12801584

llvm-svn: 171512

llvm-svn: 171511

llvm-svn: 171510

llvm-svn: 171509

llvm-svn: 171508

llvm-svn: 171507

This patch fixes the PPC eh_frame definitions for the personality and 
frame unwinding for PIC objects. It makes PIC build correctly creates
relative relocations in the '.rela.eh_frame' segments and thus avoiding
a text relocation that generates a DT_TEXTREL segments in link phase.

llvm-svn: 171506

llvm-svn: 171499

llvm-svn: 171496

llvm-svn: 171489

llvm-svn: 171487

llvm-svn: 171475

string offset section.

llvm-svn: 171474

llvm-svn: 171473

Move the loop vectorizer from O2 to O3. It looks like the increase in code size actually hurts the performance on many programs.

llvm-svn: 171471

llvm-svn: 171470