| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
pass into the SelectionDAG itself rather than snooping on the
implementation of that pass as exposed by the TargetMachine. This
removes the last direct client of the ScalarTargetTransformInfo class
outside of the TTI pass implementation.
llvm-svn: 171625
|
|
|
|
|
|
|
| |
This isn't optimal either but fixes a massive compile time regression from the
attribute uniquing work.
llvm-svn: 171624
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
as long as the reduction chain is used in the LHS.
PR14803.
llvm-svn: 171583
|
|
|
|
|
|
|
|
|
|
|
| |
leaving this undefined, and despite the sentence in the standard that
seems to require it, I'll cede the point and assume its a bug in the
wording. Other parts of POSIX regularly allow for things to be -1
instead of undefined, this should too. Makes things more consistent too.
This should have to real impact for folks though.
llvm-svn: 171574
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
because conditions in the next case prevented from doing anything nasty.
llvm-svn: 171549
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
objc_retainAutorelasedReturnValue.
llvm-svn: 171535
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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: 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
|
|
|
|
|
|
| |
dont have this hook.
llvm-svn: 171489
|
|
|
|
| |
llvm-svn: 171487
|
|
|
|
| |
llvm-svn: 171475
|
|
|
|
|
|
| |
string offset section.
llvm-svn: 171474
|
|
|
|
|
|
| |
size actually hurts the performance on many programs.
llvm-svn: 171471
|