so we don't want it to show up in the stable 3.1 interface.

While at it, add a comment about why LTOCodeGenerator manually creates the
internalize pass.

llvm-svn: 154807

To be used in printing unprintable source in clang diagnostics.
Patch by Seth Cantrell, with a minor fix for mingw by me.

llvm-svn: 154805

llvm-svn: 154802

To be used in printing unprintable source in clang diagnostics.
Patch by Seth Cantrell!

llvm-svn: 154800

llvm-svn: 154791

llvm-svn: 154778

Make member variables of AsmToken private. Remove unnecessary forward declarations. Remove an unnecessary include.

llvm-svn: 154775

llvm-svn: 154766

llvm-svn: 154750

thinking of generalizing it to be able to specify other freedoms beyond accuracy
(such as that NaN's don't have to be respected).  I'd like the 3.1 release (the
first one with this metadata) to have the more generic name already rather than
having to auto-upgrade it in 3.2.

llvm-svn: 154744

Without this gcc doesn't allow us to put a StringMap into a
std::map. Works with clang though.

llvm-svn: 154737

llvm-svn: 154734

This is a special flag for targets that really want their block
terminators in the DAG. The default scheduler cannot handle this
correctly, so it becomes the specialized scheduler's responsibility to
schedule terminators.

llvm-svn: 154712

llvm-svn: 154700

Remove getElfArchType from ELF.h. It's only used in ELFObjectFile.cpp and there's already a copy there. ELF.h was hiding the one there and causing an unused function warning.

llvm-svn: 154657

directly instead of a user Instruction. This allows them to test
whether a def dominates a particular operand if the user instruction
is a PHI.

llvm-svn: 154631

llvm-svn: 154616

of zero-initialized sections, virtual sections and common symbols
and preventing the loading of sections which are not required for
execution such as debug information.

Patch by Andy Kaylor!

llvm-svn: 154610

llvm-svn: 154580

llvm-svn: 154527

llvm-svn: 154518

FoldingSet is implemented as a chained hash table. When there is a hash
collision during insertion, which is common as we fill the table until a
load factor of 2.0 is hit, we walk the chained elements, comparing every
operand with the new element's operands. This can be very expensive if the
MDNode has many operands.

We sacrifice a word of space in MDNode to cache the full hash value, reducing
compares on collision to a minimum. MDNode grows from 28 to 32 bytes + operands
on x86. On x86_64 the new bits fit nicely into existing padding, not growing
the struct at all.

The actual speedup depends a lot on the test case and is typically between
1% and 2% for C++ code with clang -c -O0 -g.

llvm-svn: 154497

llvm-svn: 154496

binary and assembly. Patch by Carlo Kok.  Emitting was inspired by but not based
on the D llvm bindings. 

llvm-svn: 154493

llvm-svn: 154488

StringMap. This was redundant and unnecessarily bloated the MDString class.

Because the MDString class is a "Value" and will never have a "name", and
because the Name field in the Value class is a pointer to a StringMap entry, we
repurpose the Name field for an MDString. It stores the StringMap entry in the
Name field, and uses the normal methods to get the string (name) back.

PR12474

llvm-svn: 154429

Patch by Dmitri Shubin!

llvm-svn: 154391

rational number, eg as 2.5 rather than 5, 2.  OK'd by Peter Collingbourne.

llvm-svn: 154387

Take this opportunity to generalize the indirectbr bailout logic for
loop transformations. CFG transformations will never get indirectbr
right, and there's no point trying.

llvm-svn: 154386

llvm-svn: 154375

llvm-svn: 154371

legalizer always use the DAG entry node. This is wrong when the libcall is
emitted as a tail call since it effectively folds the return node. If
the return node's input chain is not the entry (i.e. call, load, or store)
use that as the tail call input chain.

PR12419
rdar://9770785
rdar://11195178

llvm-svn: 154370

llvm-svn: 154329

A couple of cases where we were accidentally creating constant conditions by
something like "x == a || b" instead of "x == a || x == b". In one case a
conditional & then unreachable was used - I transformed this into a direct
assert instead.

llvm-svn: 154324

llvm-svn: 154312

llvm-svn: 154306

optimizations which are valid for position independent code being linked
into a single executable, but not for such code being linked into
a shared library.

I discussed the design of this with Eric Christopher, and the decision
was to support an optional bit rather than a completely separate
relocation model. Fundamentally, this is still PIC relocation, its just
that certain optimizations are only valid under a PIC relocation model
when the resulting code won't be in a shared library. The simplest path
to here is to expose a single bit option in the TargetOptions. If folks
have different/better designs, I'm all ears. =]

I've included the first optimization based upon this: changing TLS
models to the *Exec models when PIE is enabled. This is the LLVM
component of PR12380 and is all of the hard work.

llvm-svn: 154294

in TargetLowering. There was already a FIXME about this location being
odd. The interface is simplified as a consequence. This will also make
it easier to change TLS models when compiling with PIE.

llvm-svn: 154292

value pointer by making the value pointer into a pointer-int pair with 2 bits
available for flags.

llvm-svn: 154279

optimizers could do this for us, but expecting partial SROA of classes
with template methods through cloning is probably expecting too much
heroics. With this change, the begin/end pointer pairs which indicate
the status of each loop iteration are actually passed directly into each
layer of the combine_data calls, and the inliner has a chance to see
when most of the combine_data function could be deleted by inlining.
Similarly for 'length'.

We have to be careful to limit the places where in/out reference
parameters are used as those will also defeat the inliner / optimizers
from properly propagating constants.

With this change, LLVM is able to fully inline and unroll the hash
computation of small sets of values, such as two or three pointers.
These now decompose into essentially straight-line code with no loops or
function calls.

There is still one code quality problem to be solved with the hashing --
LLVM is failing to nuke the alloca. It removes all loads from the
alloca, leaving only lifetime intrinsics and dead(!!) stores to the
alloca. =/ Very unfortunate.

llvm-svn: 154264