update testcase to make sure we generate debug info for walrus
by adding a non-trivial constructor and verify that we don't
emit an ODR signature for the type.

llvm-svn: 187393

sure the comments for each testcase are a bit easier to distinguish.

llvm-svn: 187392

llvm-svn: 187385

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

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

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

[stackprotector] Changed isNoopBitcast/sameNoopInput to take TargetLoweringBase instead of TargetLowering.

Both functions only use functionality from TargetLoweringBase.

rdar://13935163

llvm-svn: 186874

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

Added missing - in the header of PrologEpilogInserter.h so that editors properly realize it is a c++ header and not a c header.

llvm-svn: 186801

Fix uninitialized memory read found by MemorySanitizer: always set output parameter of ConvergingScheduler::SchedBoundary::getOtherResourceCount

llvm-svn: 186658

llvm-svn: 186632

llvm-svn: 186527

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