where the element is of a basic builtin type.  For example, to get
an i8* use getInt8PtrTy.

llvm-svn: 83379

ConstantFoldLoadThroughGEPConstantExpr.

llvm-svn: 83311

llvm-svn: 83274

llvm-svn: 82990

when the loop inspects the bitcast operand.

llvm-svn: 82928

llvm-svn: 82927

llvm-svn: 82700

rather structs passed by value.
This fixes PR5038.

llvm-svn: 82689

llvm-svn: 82355

update the code which was broken by this.

llvm-svn: 82327

Reviewed by Dan Gohman.

llvm-svn: 82300

argpromote to avoid invalidating an iterator.  This fixes PR4977.
All clang tests now pass with expensive checking (on my system 
at least).

llvm-svn: 81843

within the notional bounds of the static type of the getelementptr (which
is not the same as "inbounds") from GlobalOpt into a utility routine,
and use it in ConstantFold.cpp to check whether there are any mis-behaved
indices.

llvm-svn: 81478

llvm-svn: 81250

compile-time constant integers or that are out of bounds for their
corresponding static array types. These can cause aliasing that
GlobalOpt assumes won't happen.

llvm-svn: 81165

an aggregate store overlapping a different aggregate store, despite
the stores having distinct addresses.

llvm-svn: 81164

is missing the inbounds flag. This is slightly conservative, but it
avoids problems with two constants pointing to the same address but
getting distinct entries in the Memory DenseMap.

llvm-svn: 81163

into a getelementptr ConstantExpr.

llvm-svn: 81162

llvm-svn: 81161

llvm-svn: 80903

llvm-svn: 80871

re-commit r66920 (which has been backed out in r66953) I may have more luck this time. I'll back out if needed...

llvm-svn: 80858

llvm-svn: 80708

llvm-svn: 80706

for sanity.  This didn't turn up any bugs.

Change CallGraphNode to maintain its "callsite" information in the 
call edges list as a WeakVH instead of as an instruction*.  This fixes
a broad class of dangling pointer bugs, and makes CallGraph have a number
of useful invariants again.  This fixes the class of problem indicated
by PR4029 and PR3601.

llvm-svn: 80663

llvm-svn: 80540

llvm-svn: 80539

instead of CallGraphNode*'s.  This also papers over a callgraph
problem where a pass (in this case, MemCpyOpt) introduces a new
function into the module (llvm.memset.i64) but doesn't add it to
the call graph (nor should it, since it is a function pass).

While it might be a good idea for MemCpyOpt to not synthesize 
functions in a runOnFunction(), there is no need for FunctionAttrs
to be boneheaded, so fix it there.  This fixes an assertion building
176.gcc.

llvm-svn: 80535

indirect function pointer, inline it, then go to delete the body.
The problem is that the callgraph had other references to the function,
though the inliner had no way to know it, so we got a dangling pointer
and an invalid iterator out of the deal.

The fix to this is pretty simple: stop the inliner from deleting the
function by knowing that there are references to it.  Do this by making
CallGraphNodes contain a refcount.  This requires moving deletion of 
available_externally functions to the module-level cleanup sweep where
it belongs.

llvm-svn: 80533

argpromotion and structretpromote.  Basically, when replacing
a function, they used the 'changeFunction' api which changes
the entry in the function map (and steals/reuses the callgraph
node).

This has some interesting effects: first, the problem is that it doesn't
update the "callee" edges in any callees of the function in the call graph.
Second, this covers for a major problem in all the CGSCC pass stuff, which 
is that it is completely broken when functions are deleted if they *don't*
reuse a CGN.  (there is a cute little fixme about this though :).

This patch changes the protocol that CGSCC passes must obey: now the CGSCC 
pass manager copies the SCC and preincrements its iterator to avoid passes
invalidating it.  This allows CGSCC passes to mutate the current SCC.  However
multiple passes may be run on that SCC, so if passes do this, they are now
required to *update* the SCC to be current when they return.

Other less interesting parts of this patch are that it makes passes update
the CG more directly, eliminates changeFunction, and requires clients of
replaceCallSite to specify the new callee CGN if they are changing it.

llvm-svn: 80527

Use MDNodes to encode debug info in llvm IR.

llvm-svn: 80406

llvm-svn: 80334

calls into a function and if the calls bring in arrays, try to merge
them together to reduce stack size.  For example, in the testcase
we'd previously end up with 4 allocas, now we end up with 2 allocas.

As described in the comments, this is not really the ideal solution
to this problem, but it is surprisingly effective.  For example, on
176.gcc, we end up eliminating 67 arrays at "gccas" time and another
24 at "llvm-ld" time.

One piece of concern that I didn't look into: at -O0 -g with
forced inlining this will almost certainly result in worse debug
info.  I think this is acceptable though given that this is a case
of "debugging optimized code", and we don't want debug info to
prevent the optimizer from doing things anyway.

llvm-svn: 80215

llvm-svn: 80204

and other code cleanups.  No functionality change.

llvm-svn: 80199

llvm-svn: 80073

and introduce a new Instruction::isIdenticalTo which tests for full
identity, including the SubclassOptionalData flags. Also, fix the
Instruction::clone implementations to preserve the SubclassOptionalData
flags. Finally, teach several optimizations how to handle
SubclassOptionalData correctly, given these changes.

This fixes the counterintuitive behavior of isIdenticalTo not comparing
the full value, and clone not returning an identical clone, as well as
some subtle bugs that could be caused by these.

Thanks to Nick Lewycky for reporting this, and for an initial patch!

llvm-svn: 80038

Update DebugInfo interface to use metadata, instead of special named llvm.dbg.... global variables, to encode debugging information in llvm IR. This is mostly a mechanical change that tests metadata support very well.

This change speeds up llvm-gcc by more then 6% at "-O0 -g" (measured by compiling InstructionCombining.cpp!)

llvm-svn: 79977

the command line.  This gives llvm-gcc developers
a way to control inlining (documented as "not intended
for end users").

llvm-svn: 79966

member out of line. ftostr is not particularly speedy,
so that method is presumably not perf sensitive.

llvm-svn: 79885