llvm-svn: 66454

be needed now that these intrinsics are marked
as not accessing memory.

llvm-svn: 66420

llvm-svn: 66384

llvm-svn: 66381

llvm-svn: 66369

llvm-svn: 66362

"boolify" pointers, generating really awful code because getting the pointer
value requires a load itself.  Before:

_foo:
	movb	$1, _X.b
	ret
_get:
	xorl	%ecx, %ecx
	movb	_X.b, %al
	testb	%al, %al
	movl	$_Y, %eax
	cmove	%ecx, %eax
	ret

With the xform disabled:

_foo:
	movl	$_Y, _X
	ret
_get:
	movl	_X, %eax
	ret

llvm-svn: 66351

and extern_weak_odr.  These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global.  In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time.   This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function.  If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body.  The
code generators on the other hand map weak and weak_odr linkage
to the same thing.

llvm-svn: 66339

Lennart Augustsson!

llvm-svn: 66272

to find a tiny mouse hole to squeeze through, it struck
me that globals without a name can be considered internal
since they can't be referenced from outside the current
module.  This patch makes GlobalOpt give them internal
linkage.  Also done for aliases even though they always
have names, since in my opinion anonymous aliases should
be allowed for consistency with global variables and
functions.  So if that happens one day, this code is ready!

llvm-svn: 66267

llvm-svn: 66233

We are still not out of woods yet.

llvm-svn: 66232

llvm-svn: 66224

If non constant local GV named A is used by a constant local GV named B (e.g. llvm.dbg.variable) and B is not used by anyone else then eliminate A as well as B.

In other words, debug info should not interfere in removal of unused GV.
--This life, and those below, will be ignored--

M    test/Transforms/GlobalOpt/2009-03-03-dbg.ll
M    lib/Transforms/IPO/GlobalOpt.cpp

llvm-svn: 66167

llvm-svn: 66083

If a global constant is dead then global's debug info should not prevent the optimizer in deleting the global. And while deleting global, delete global's debug info also.

llvm-svn: 65994

llvm-svn: 65971

llvm-svn: 65908

This is ugly, but I can't figure out a quick way out of this.

llvm-svn: 65889

here.  Since we only do the transform if there is
one use, strip off any such users in the hope of
making the transform fire more often.

llvm-svn: 64926

llvm-svn: 64915

crash because the alias would still be using the aliasee when the
aliasee was deleted.

llvm-svn: 64844

llvm-svn: 64773

one-definition-rule llvm-gcc changes (coming soon
to a tree near you!).

llvm-svn: 64588

alias can be morphed into the target.  Implement this
transform, and fix a crash in the existing transform at
the same time.

llvm-svn: 64583

llvm-svn: 63198

llvm-svn: 62956

llvm-svn: 62877

There is now a direct way from value-use-iterator to incoming block in PHINode's API.
This way we avoid the iterator->index->iterator trip, and especially the costly
getOperandNo() invocation. Additionally there is now an assertion that the iterator
really refers to one of the PHI's Uses.

llvm-svn: 62869

llvm-svn: 62788

doing very similar pointer capture analysis.
Factor out the common logic.  The new version
is from FunctionAttrs since it does a better
job than the version in BasicAliasAnalysis

llvm-svn: 62461

llvm-svn: 62279

vector and extraneous loop over it, 2) not delete globals used by
phis/selects etc which could actually be useful.  This fixes PR3321.
Many thanks to Duncan for narrowing this down.

llvm-svn: 62201

llvm-svn: 62165

back to 200; 400 seems to be too high, loses more than
it gains.

llvm-svn: 62107

suggested by Chris.

llvm-svn: 62099

compensation for turning off gcc's inliner.  This gets
us closer to the amount of inlining we were getting before.
It is not a win on everything, of course, but seems to
gain overall.

llvm-svn: 62058

llvm-svn: 61991

llvm-svn: 61969

llvm-svn: 61879