llvm-svn: 149926

The problem initially reported by Mozilla folks (http://code.google.com/p/address-sanitizer/issues/detail?id=20),
but it also prevents us from enabling LLVM bootstrap with AddressSanitizer.

llvm-svn: 149925

llvm-svn: 149922

We have automatic local renumbering now.

llvm-svn: 149920

This CL delays reading of function bodies from initial parse until
materialization, allowing overlap of compilation with bitcode download.

llvm-svn: 149918

instead of always using ConstantVector.

llvm-svn: 149912

llvm-svn: 149910

were no 'unwind' instructions being generated before this, so this is in effect
a no-op.

llvm-svn: 149906

llvm-svn: 149905

remove the code that handles them.

llvm-svn: 149901

llvm-svn: 149898

llvm-svn: 149897

some architectures. These are useful for interacting with multiarch or
bi-arch GCC (or GCC-based) toolchains.

llvm-svn: 149895

llvm-svn: 149887

llvm-svn: 149874

llvm-svn: 149866

llvm-svn: 149865

Reorder includes while at it.

llvm-svn: 149863

change.

llvm-svn: 149861

Move some llvm_unreachable's from r149849 out of switch statements to satisfy -Wcovered-switch-default

llvm-svn: 149860

llvm-svn: 149859

llvm-svn: 149857

llvm-svn: 149856

llvm-svn: 149849

llvm-svn: 149848

 * Most of the transforms come through intact by having each transformed load or
store copy the ordering and synchronization scope of the original.
 * The transform that turns a global only accessed in main() into an alloca
(since main is non-recursive) with a store of the initial value uses an
unordered store, since it's guaranteed to be the first thing to happen in main.
(Threads may have started before main (!) but they can't have the address of a
function local before the point in the entry block we insert our code.)
 * The heap-SRoA transforms are disabled in the face of atomic operations. This
can probably be improved; it seems odd to have atomic accesses to an alloca
that doesn't have its address taken.

AnalyzeGlobal keeps track of the strongest ordering found in any use of the
global. This is more information than we need right now, but it's cheap to
compute and likely to be useful.

llvm-svn: 149847

llvm-svn: 149846

llvm-svn: 149845

predecessor then it's Src.

llvm-svn: 149843

above.

llvm-svn: 149841

llvm-svn: 149839

logic by half: isOnlyReachableViaThisEdge was trying to be clever and
handle the case of a branch to a basic block which is contained in a
loop.  This costs a domtree lookup and is completely useless due to
GVN's position in the pass pipeline: all loops have preheaders at this
point, which means it is enough for isOnlyReachableViaThisEdge to check
that Dst has only one predecessor.  (I checked this theoretical argument
by running over the entire nightly testsuite, and indeed it is so!).

llvm-svn: 149838

compiling sqlite3, by only doing dom queries after the cheap check
rather than interleaved with it.

llvm-svn: 149836

llvm-svn: 149834

llvm-svn: 149833

llvm-svn: 149832

llvm-svn: 149823

llvm-svn: 149816

convert at least one client over to use them. Subsequent patches both to
LLVM and Clang will try to convert more people over to a common set of
predicates.

This round of predicates is focused on OS-categorization predicates.

llvm-svn: 149815

llvm-svn: 149814