| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
32-bit symbols have "_" as global prefix, but when forming the name of
COMDAT sections this prefix is ignored. The current behavior assumes that
this prefix is always present which is not the case for 64-bit and names
are truncated.
llvm-svn: 187356
|
| |
|
|
|
|
| |
This makes LLVM emit the same signature regardless of host and target endianess.
llvm-svn: 187304
|
| |
|
|
|
|
|
|
| |
There doesn't appear to be any reason to put this variable on the heap.
I'm suspicious of the LexicalScope above that we stuff in a map and then
delete afterward, but I'm just trying to get the valgrind bot clean.
llvm-svn: 187301
|
| |
|
|
|
|
|
|
|
|
| |
Adds unit tests for it too.
Split BasicBlockUtils into an analysis-half and a transforms-half, and put the
analysis bits into a new Analysis/CFG.{h,cpp}. Promote isPotentiallyReachable
into llvm::isPotentiallyReachable and move it into Analysis/CFG.
llvm-svn: 187283
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
conditions
Merge consecutive if-regions if they contain identical statements.
Both transformations reduce number of branches. The transformation
is guarded by a target-hook, and is currently enabled only for +R600,
but the correctness has been tested on X86 target using a variety of
CPU benchmarks.
Patch by: Mei Ye
llvm-svn: 187278
|
| |
|
|
| |
llvm-svn: 187245
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
type units.
Initially this support is used in the computation of an ODR checker
for C++. For now we're attaching it to the DIE, but in the future
it will be attached to the type unit.
This also starts breaking out types into the separation for type
units, but without actually splitting the DIEs.
In preparation for hashing the DIEs this adds a DIEString type
that contains a StringRef with the string contained at the label.
llvm-svn: 187213
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
CustomLowerNode was not being called during SplitVectorOperand,
meaning custom legalization could not be used by targets.
This also adds a test case for NVPTX that depends on this custom
legalization.
Differential Revision: http://llvm-reviews.chandlerc.com/D1195
Attempt to fix the buildbots by making the X86 test I just added platform independent
llvm-svn: 187202
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 187198. It broke the bots.
The soft float test probably needs a -triple because of name differences.
On the hard float test I am getting a "roundss $1, %xmm0, %xmm0", instead of
"vroundss $1, %xmm0, %xmm0, %xmm0".
llvm-svn: 187201
|
| |
|
|
|
|
|
|
|
|
|
|
| |
CustomLowerNode was not being called during SplitVectorOperand,
meaning custom legalization could not be used by targets.
This also adds a test case for NVPTX that depends on this custom
legalization.
Differential Revision: http://llvm-reviews.chandlerc.com/D1195
llvm-svn: 187198
|
| |
|
|
| |
llvm-svn: 187141
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous change to local live range allocation also suppressed
eviction of local ranges. In rare cases, this could result in more
expensive register choices. This commit actually revives a feature
that I added long ago: check if live ranges can be reassigned before
eviction. But now it only happens in rare cases of evicting a local
live range because another local live range wants a cheaper register.
The benefit is improved code size for some benchmarks on x86 and armv7.
I measured no significant compile time increase and performance
changes are noise.
llvm-svn: 187140
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also avoid locals evicting locals just because they want a cheaper register.
Problem: MI Sched knows exactly how many registers we have and assumes
they can be colored. In cases where we have large blocks, usually from
unrolled loops, greedy coloring fails. This is a source of
"regressions" from the MI Scheduler on x86. I noticed this issue on
x86 where we have long chains of two-address defs in the same live
range. It's easy to see this in matrix multiplication benchmarks like
IRSmk and even the unit test misched-matmul.ll.
A fundamental difference between the LLVM register allocator and
conventional graph coloring is that in our model a live range can't
discover its neighbors, it can only verify its neighbors. That's why
we initially went for greedy coloring and added eviction to deal with
the hard cases. However, for singly defined and two-address live
ranges, we can optimally color without visiting neighbors simply by
processing the live ranges in instruction order.
Other beneficial side effects:
It is much easier to understand and debug regalloc for large blocks
when the live ranges are allocated in order. Yes, global allocation is
still very confusing, but it's nice to be able to comprehend what
happened locally.
Heuristics could be added to bias register assignment based on
instruction locality (think late register pairing, banks...).
Intuituvely this will make some test cases that are on the threshold
of register pressure more stable.
llvm-svn: 187139
|
| |
|
|
| |
llvm-svn: 187135
|
| |
|
|
|
|
| |
Consider which set is being increased or decreased before comparing.
llvm-svn: 187110
|
| |
|
|
|
|
| |
the units.
llvm-svn: 187109
|
| |
|
|
| |
llvm-svn: 187107
|
| |
|
|
|
|
|
|
| |
There's no need to specify a flag to omit frame pointer elimination on non-leaf
nodes...(Honestly, I can't parse that option out.) Use the function attribute
stuff instead.
llvm-svn: 187093
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prior to this patch, IfConverter may widen the cases where a sequence of
instructions were executed because of the way it uses nested predicates. This
result in incorrect execution.
For instance, Let A be a basic block that flows conditionally into B and B be a
predicated block.
B can be predicated with A.BrToBPredicate into A iff B.Predicate is less
"permissive" than A.BrToBPredicate, i.e., iff A.BrToBPredicate subsumes
B.Predicate.
The IfConverter was checking the opposite: B.Predicate subsumes
A.BrToBPredicate.
<rdar://problem/14379453>
llvm-svn: 187071
|
| |
|
|
|
|
|
| |
This commit also implements these functions for R600 and removes a test
case that was relying on the buggy behavior.
llvm-svn: 187007
|
| |
|
|
| |
llvm-svn: 186994
|
| |
|
|
|
|
|
|
|
|
| |
TargetLoweringBase instead of TargetLowering.
Both functions only use functionality from TargetLoweringBase.
rdar://13935163
llvm-svn: 186874
|
| |
|
|
|
|
|
|
|
|
| |
function.
No functionality change.
rdar://13935163
llvm-svn: 186868
|
| |
|
|
|
|
|
|
|
| |
Use the function attributes to pass along the stack protector buffer size.
Now that we have robust function attributes, don't use a command line option to
specify the stack protecto buffer size.
llvm-svn: 186863
|
| |
|
|
| |
llvm-svn: 186851
|
| |
|
|
|
|
| |
properly realize it is a c++ header and not a c header.
llvm-svn: 186801
|
| |
|
|
|
|
| |
parameter of ConvergingScheduler::SchedBoundary::getOtherResourceCount
llvm-svn: 186658
|
| |
|
|
|
|
| |
make more sense.
llvm-svn: 186632
|
| |
|
|
| |
llvm-svn: 186527
|
| |
|
|
|
|
| |
every access.
llvm-svn: 186482
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 186470
|
| |
|
|
|
|
|
| |
This centralizes the handling of O_BINARY and opens the way for hiding more
differences (like how open behaves with directories).
llvm-svn: 186447
|
| |
|
|
|
|
|
|
|
|
| |
These floats all represented block frequencies anyway, so just use the
BlockFrequency class directly.
Some floating point computations remain in tryLocalSplit(). They are
estimating spill weights which are still floats.
llvm-svn: 186435
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
Remove floating point computations from SpillPlacement.cpp.
Patch by Benjamin Kramer!
Use the BlockFrequency class instead of floats in the Hopfield network
computations. This rescales the node Bias field from a [-2;2] float
range to two block frequencies BiasN and BiasP pulling in opposite
directions. This construct has a more predictable behavior when block
frequencies saturate.
The per-node scaling factors are no longer necessary, assuming the block
frequencies around a bundle are consistent.
This patch can cause the register allocator to make different spilling
decisions. The differences should be small.
llvm-svn: 186434
|
| |
|
|
| |
llvm-svn: 186371
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can have a FrameSetup in one basic block and the matching FrameDestroy
in a different basic block when we have struct byval. In that case, SPAdj
is not zero at beginning of the basic block.
Modify PEI to correctly set SPAdj at beginning of each basic block using
DFS traversal. We used to assume SPAdj is 0 at beginning of each basic block.
PEI had an assert SPAdjCount || SPAdj == 0.
If we have a Destroy <n> followed by a Setup <m>, PEI will assert failure.
We can add an extra condition to make sure the pairs are matched:
The pairs start with a FrameSetup.
But since we are doing a much better job in the verifier, this patch removes
the check in PEI.
PR16393
llvm-svn: 186364
|
| |
|
|
|
|
|
|
|
|
|
| |
1> on every path through the CFG, a FrameSetup <n> is always followed by a
FrameDestroy <n> and a FrameDestroy is always followed by a FrameSetup.
2> stack adjustments are identical on all CFG edges to a merge point.
3> frame is destroyed at end of a return block.
PR16393
llvm-svn: 186350
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a comment at the top of DAGTypeLegalizer::PerformExpensiveChecks
which, in part, says:
// Note that these invariants may not hold momentarily when processing a node:
// the node being processed may be put in a map before being marked Processed.
Unfortunately, this assert would be valid only if the above-mentioned invariant
held unconditionally. This was causing llc to assert when, in fact,
everything was fine.
Thanks to Richard Sandiford for investigating this issue!
Fixes PR16562.
llvm-svn: 186338
|
| |
|
|
| |
llvm-svn: 186312
|
| |
|
|
| |
llvm-svn: 186297
|
| |
|
|
| |
llvm-svn: 186295
|
| |
|
|
| |
llvm-svn: 186276
|
| |
|
|
|
|
| |
size.
llvm-svn: 186274
|
| |
|
|
| |
llvm-svn: 186243
|
| |
|
|
|
|
|
|
|
|
| |
http://lab.llvm.org:8013/builders/clang-x86_64-darwin11-nobootstrap-RAincremental/builds/4328
Original commit log:
Use the function attributes to pass along the stack protector buffer
size.
llvm-svn: 186234
|
| |
|
|
|
|
|
| |
Now that we have robust function attributes, don't use a command line option to
specify the stack protecto buffer size.
llvm-svn: 186217
|
| |
|
|
|
|
|
|
|
|
|
| |
Address calculation for gather/scather in vectorized code can incur a
significant cost making vectorization unbeneficial. Add infrastructure to add
cost.
Tests and cost model for targets will be in follow-up commits.
radar://14351991
llvm-svn: 186187
|
| |
|
|
|
|
|
| |
replaceFrameIndices(MF) will iterate over the BBs and call
replaceFrameIndices(BB). No functionality change.
llvm-svn: 186141
|
| |
|
|
|
|
| |
size.
llvm-svn: 186098
|
| |
|
|
|
|
|
|
|
|
|
| |
MF is normally initialized in AsmPrinter::SetupMachineFunction, but if the file
contains only globals (no functions), then we need this to be initialized
because, when encountering an error, lowerConstant() references it.
This should fix the non-deterministic failures of
test/CodeGen/X86/nonconst-static-iv.ll, etc.
llvm-svn: 186068
|