| Commit message (Collapse) | Author | Age | Files | Lines | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
(if available) as we go so that we get simple constantexprs not insane ones.
This fixes the failure of clang/test/CodeGenCXX/virtual-base-ctor.cpp
that the previous iteration of this patch had.
llvm-svn: 121111
 | 
| | 
| 
| 
| 
| 
|  | 
CodeGenCXX/virtual-base-ctor.cpp.
llvm-svn: 121102
 | 
| | 
| 
| 
| 
| 
|  | 
put in a global variable's initializer.
llvm-svn: 121100
 | 
| | 
| 
| 
| 
| 
|  | 
No functionality change.
llvm-svn: 121042
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
optimization.
Consider:
static void foo() {
  A = alloca
  ...
}
static void bar() {
  B = alloca
  ...
  call foo();
}
void main() {
  bar()
}
The inliner proceeds bottom up, but lets pretend it decides not to inline foo
into bar.  When it gets to main, it inlines bar into main(), and says "hey, I
just inlined an alloca "B" into main, lets remember that.  Then it keeps going
and finds that it now contains a call to foo.  It decides to inline foo into
main, and says "hey, foo has an alloca A, and I have an alloca B from another
inlined call site, lets reuse it".  The problem with this of course, is that 
the lifetime of A and B are nested, not disjoint.
Unfortunately I can't create a reasonable testcase for this: the one in the
PR is both huge and extremely sensitive, because you minor tweaks end up
causing foo to get inlined into bar too early.  We already have tests for the
basic alloca merging optimization and this does not break them.
llvm-svn: 120995
 | 
| | 
| 
| 
|  | 
llvm-svn: 120993
 | 
| | 
| 
| 
| 
| 
|  | 
and vaarg instructions.
llvm-svn: 118845
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
testing for dereferenceable pointers into a helper function,
isDereferenceablePointer.  Teach it how to reason about GEPs
with simple non-zero indices.
Also eliminate ArgumentPromtion's IsAlwaysValidPointer,
which didn't check for weak externals or out of range gep
indices.
llvm-svn: 118840
 | 
| | 
| 
| 
|  | 
llvm-svn: 118804
 | 
| | 
| 
| 
| 
| 
|  | 
it, and to be consistent.
llvm-svn: 118692
 | 
| | 
| 
| 
| 
| 
|  | 
arbitrary memory into a helper function, and adjust some comments.
llvm-svn: 118687
 | 
| | 
| 
| 
| 
| 
|  | 
chaining and simplify FunctionAttrs' GetModRefBehavior logic.
llvm-svn: 118660
 | 
| | 
| 
| 
|  | 
llvm-svn: 118627
 | 
| | 
| 
| 
| 
| 
| 
|  | 
memory. This isn't a real improvement with present day AliasAnalysis
implementations; it's mainly for consistency.
llvm-svn: 118624
 | 
| | 
| 
| 
|  | 
llvm-svn: 118617
 | 
| | 
| 
| 
|  | 
llvm-svn: 118430
 | 
| | 
| 
| 
|  | 
llvm-svn: 118417
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
to optionally look for constant or local (alloca) memory.
Teach BasicAliasAnalysis::pointsToConstantMemory to look through Select
and Phi nodes, and to support looking for local memory.
Remove FunctionAttrs' PointsToLocalOrConstantMemory function, now that
AliasAnalysis knows all the tricks that it knew.
llvm-svn: 118412
 | 
| | 
| 
| 
| 
| 
|  | 
knows about intrinsic functions.
llvm-svn: 118410
 | 
| | 
| 
| 
| 
| 
|  | 
the code more self-documenting.
llvm-svn: 118171
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
threshold given to createFunctionInliningPass().
Both opt -O3 and clang would silently ignore the -inline-threshold option.
llvm-svn: 118117
 | 
| | 
| 
| 
| 
| 
|  | 
it claiming not to have side-effects is no longer needed.
llvm-svn: 117789
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
consider it to be readonly.  In fact, don't even consider it to be
readonly if it does a volatile load from an AllocaInst either (it
is debatable as to whether readonly would be correct or not in this
case; play safe for the moment).  This fixes PR8279.
llvm-svn: 117783
 | 
| | 
| 
| 
| 
| 
| 
|  | 
it looks like maybe it was supposed to be used in the
test...), so zap it (gcc-4.6 warning).
llvm-svn: 117023
 | 
| | 
| 
| 
| 
| 
|  | 
uint64_t, plus fixes for places I missed before.
llvm-svn: 116875
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
exposes an initializeMyPassFunction(), which
must be called in the pass's constructor.  This function uses static dependency declarations to recursively initialize
the pass's dependencies.
Clients that only create passes through the createFooPass() APIs will require no changes.  Clients that want to use the
CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h
before parsing commandline arguments.
I have tested this with all standard configurations of clang and llvm-gcc on Darwin.  It is possible that there are problems
with the static dependencies that will only be visible with non-standard options.  If you encounter any crash in pass
registration/creation, please send the testcase to me directly.
llvm-svn: 116820
 | 
| | 
| 
| 
| 
| 
|  | 
Fixes PR8389.
llvm-svn: 116812
 | 
| | 
| 
| 
|  | 
llvm-svn: 116749
 | 
| | 
| 
| 
|  | 
llvm-svn: 116443
 | 
| | 
| 
| 
|  | 
llvm-svn: 116387
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
perform initialization without static constructors AND without explicit initialization
by the client.  For the moment, passes are required to initialize both their
(potential) dependencies and any passes they preserve.  I hope to be able to relax
the latter requirement in the future.
llvm-svn: 116334
 | 
| | 
| 
| 
| 
| 
|  | 
create a given specialization of a function in PartialSpecialization.  If the total performance bonus across all callsites passing the same constant exceeds the specialization cost, we create the specialization.
llvm-svn: 116158
 | 
| | 
| 
| 
|  | 
llvm-svn: 115996
 | 
| | 
| 
| 
|  | 
llvm-svn: 115933
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The x86_mmx type is used for MMX intrinsics, parameters and
return values where these use MMX registers, and is also
supported in load, store, and bitcast.
Only the above operations generate MMX instructions, and optimizations
do not operate on or produce MMX intrinsics. 
MMX-sized vectors <2 x i32> etc. are lowered to XMM or split into
smaller pieces.  Optimizations may occur on these forms and the
result casted back to x86_mmx, provided the result feeds into a
previous existing x86_mmx operation.
The point of all this is prevent optimizations from introducing
MMX operations, which is unsafe due to the EMMS problem.
llvm-svn: 115243
 | 
| | 
| 
| 
|  | 
llvm-svn: 114999
 | 
| | 
| 
| 
| 
| 
| 
|  | 
"external" even when doing lazy bitcode loading.  This was broken because
a function that is not materialized fails the !isDeclaration() test.
llvm-svn: 114666
 | 
| | 
| 
| 
| 
| 
|  | 
attribute(used).
llvm-svn: 113911
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This reverts commit r113632
Conflicts:
	cmake/modules/AddLLVM.cmake
llvm-svn: 113819
 | 
| | 
| 
| 
|  | 
llvm-svn: 113632
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
Switch from isWeakForLinker to mayBeOverridden which is more accurate.
Add more statistics and debugging info. Add comments. Move static function
outside anonymous namespace.
llvm-svn: 113190
 | 
| | 
| 
| 
|  | 
llvm-svn: 113106
 | 
| | 
| 
| 
| 
| 
|  | 
This reduces malloc traffic (yay!) and removes MergeFunctionsEqualityInfo.
llvm-svn: 113105
 | 
| | 
| 
| 
| 
| 
| 
|  | 
strong functions first to make sure they're the canonical definitions and then
do a second pass looking only for weak functions.
llvm-svn: 113104
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
two are weak, we make them thunks to a new strong function) so don't iterate
through the function list as we're modifying it.
Also add back the outermost loop which got removed during the cleanups.
llvm-svn: 112595
 | 
| | 
| 
| 
| 
| 
| 
|  | 
where we hash, compare and fold, instead of one iteration where we build up
the hash buckets and a second one to fold.
llvm-svn: 112582
 | 
| | 
| 
| 
| 
| 
|  | 
being actively maintained, improved, or extended.
llvm-svn: 112356
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
fix: add a flag to MapValue and friends which indicates whether
any module-level mappings are being made. In the common case of
inlining, no module-level mappings are needed, so MapValue doesn't
need to examine non-function-local metadata, which can be very
expensive in the case of a large module with really deep metadata
(e.g. a large C++ program compiled with -g).
This flag is a little awkward; perhaps eventually it can be moved
into the ClonedCodeInfo class.
llvm-svn: 112190
 | 
| | 
| 
| 
|  | 
llvm-svn: 112130
 | 
| | 
| 
| 
| 
| 
|  | 
and was over-complicated, and replacing it with a simple implementation.
llvm-svn: 112120
 |