GlobalVariable about LLVM's assumptions vis-a-vis Global Variable
initial values and Global Variable initializers.

This is in preparation for adding the new keyword
externally_initialized.

Specifically, the patch explains how LLVM optimizes global initializers
by assumign that global variables defined within the module are not
modified from their initial values before the start of the global
initializer.

llvm-svn: 174269

The main lists of debug info metadata attached to the compile_unit had an extra
layer of metadata nodes they went through for no apparent reason. This patch
removes that (& still passes just as much of the GDB 7.5 test suite). If anyone
can show evidence as to why these extra metadata nodes are there I'm open to
reverting this patch & documenting why they're there.

llvm-svn: 174266

This checkin makes hello world work. 

llvm-svn: 174264

llvm-svn: 174259

llvm-svn: 174251

Use the AttributeSet's iterators in AttrBuilder::hasAttributes() when
determining of the intersection of the AttrBuilder and AttributeSet is non-null.

llvm-svn: 174250

llvm-svn: 174241

says, but that's a defect (to be filed). "Cls::purevfn()" is still an odr use.

Also fixes a bug in the previous patch that caused us to not mark the function
referenced just because we didn't want to mark it odr used.

llvm-svn: 174240

Fix a bug in DAGCombine. The symptom is mistakenly optimizing expression
"x + x*x" into "x * 3.0".

llvm-svn: 174239

llvm-svn: 174237

Testing case is reduced from MultiSource/BenchMarks/Prolangs-C++/deriv1.

rdar://problem/13071590

llvm-svn: 174235

llvm-svn: 174232

llvm-svn: 174230

This Constant could be an aggregate to represent multiple values.

llvm-svn: 174228

the SCEV vector size in LoopStrengthReduce. It is observed that
the BaseRegs vector size is 4 in most cases,
and elements are frequently copied when it is initialized as
SmallVector<const SCEV *, 2> BaseRegs.
Our benchmark results show that the compilation time performance
improved by ~0.5%.

Patch by Wan Xiaofei.

llvm-svn: 174219

llvm-svn: 174210

1) allows the use of RIP-relative addressing in 32-bit LEA instructions under
   x86-64 (ILP32 and LP64)
2) separates the size of address registers in 64-bit LEA instructions from
   control by ILP32/LP64.

llvm-svn: 174208

Found by Alexander Kornienko.

llvm-svn: 174207

llvm-svn: 174205

llvm-svn: 174198

llvm-svn: 174196

llvm-svn: 174193

llvm-svn: 174186

Prepare it for vectors of pointers and handle simple cases. We don't handle
complicated cases because accumulateConstantOffset bails on pointer vectors.
Fixes selfhost on i386.

llvm-svn: 174179

This should fix a warning when building this backend.

llvm-svn: 174177

Only Linux is supported at the moment, and other platforms quickly fault. As a
result these tests would fail on non-Linux hosts. It may be worth making the
tests more generic again as more platforms are supported.

llvm-svn: 174170

llvm-svn: 174156

llvm-svn: 174152

My "excuse" for not refactoring the grammar here is to not diverge too
far from the grammar in the comments of TGParser.cpp, since I'm not
taking on the quest of majorly refactoring TGParser.cpp at the moment.

One benefit of doing this is that Ideas for refactoring and clarifying
the grammar in this document should translate almost immediately to
beneficial refactorings that can be made to TGParser.cpp.

llvm-svn: 174144

Spotted by Eli Bendersky.

llvm-svn: 174143

Drive by fix. I noticed some missing logic that might bite future
users. This shouldn't affect the final output on currently modeled
targets.

llvm-svn: 174142

llvm-svn: 174132

llvm-svn: 174131

llvm-svn: 174130

Use iterators instead of relying upon a bitmask of attributes to remove attributes from an AttrBuilder.

llvm-svn: 174123

remaining use of AliasAnalysis concepts such as isIdentifiedObject to
prove pointer inequality.

@external_compare in test/Transforms/InstSimplify/compare.ll shows a simple
case where a noalias argument can be equal to a global variable address, and
while AliasAnalysis can get away with saying that these pointers don't alias,
instsimplify cannot say that they are not equal.

llvm-svn: 174122

have any effect. Spotted by Eli in review, thanks!!!

llvm-svn: 174121

llvm-svn: 174120

be equal, since there's nothing preventing a caller from correctly predicting
the stack location of an alloca.

llvm-svn: 174119

infrastructure on MCStreamer to test for whether there is an
MCELFStreamer object available.

This is just a cleanup on the AsmPrinter side of things, moving ad-hoc
tests of random APIs to a direct type query. But the AsmParser
completely broken. There were no tests, it just blindly cast its
streamer to an MCELFStreamer and started manipulating it.

I don't have a test case -- this actually failed on LLVM's own
regression test suite. Unfortunately the failure only appears when the
stars, compilers, and runtime align to misbehave when we read a pointer
to a formatted_raw_ostream as-if it were an MCAssembler. =/

UBSan would catch this immediately.

Many thanks to Matt for doing about 80% of the debugging work here in
GDB, Jim for helping to explain how exactly to fix this, and others for
putting up with the hair pulling that ensued during debugging it.

llvm-svn: 174118