gets placed inside a main function, and should not itself be a main
function. This is silently hidden in GCC-hosted builds because the
inner main looks like a nested function declaration, which GCC supports.
In builds with compilers which do not support nested functions (by default),
this was causing an error, which caused these autoconf checks to fail,
leaving their options disabled.
This fixes test/Feature/load_module.ll on x86_64-unknown-linux-gnu
llvm-gcc selfhost builds, among other things.
This also includes a regenerated configure, as the diff is small and telling.
llvm-svn: 102288
Also, generalize ScalarEvolutions's min and max recognition to handle
some new forms of min and max that this change makes more common.
llvm-svn: 102234
This fixes a bug where calls inlined into an invoke would get
changed into an invoke but the array would keep pointing to
the (now dead) call. The improved inliner behavior is still
disabled for now.
llvm-svn: 102196
Add the instruction pointer value for debuggability.
We now get dump output that looks like this:
Call graph node for function: 'f1'<<0x1017086b0>> #uses=1
CS<0x1017046f8> calls external node
Call graph node for function: '_ZNSt6vectorIdSaIdEEC1EmRKdRKS0_'<<0x1017086f0>> #uses=1
CS<0x0> calls external node
Call graph node for function: 'f4'<<0x1017087a0>> #uses=1
CS<0x101708c88> calls function 'f3'
llvm-svn: 102194
that appear in the SCC as a result of inlining as candidates
for inlining. Change this so that it *does* consider call
sites that change from being indirect to being direct as a
result of inlining. This allows it to completely
"devirtualize" the testcase.
llvm-svn: 102146
the definition of the nsw and nuw flags to make use of it.
nsw was introduced to help optimizers answer yes to the following:
// Can we change i from i32 to i64 to eliminate the cast inside the loop?
for (int i = 0; i < n; ++i) A[i] *= 0.1;
// Can we assume that this loop will eventually terminate?
for (int i = 0; i <= n; ++i) A[i] *= 0.1;
In its current form, it isn't truly sufficient for either.
In the first case, if the increment overflows, it'll still have some
valid i32 value; sign-extending it will produce a value which is 33
homogeneous sign bits trailed by 31 independent undef bits. If i is
promoted to i64, it won't have those same values when it reaches that
point. (The compiler could recover here by reasoning about how i is
used by the load, but that's a lot more complicated and isn't always
possible.)
In the second case, there is no value for i which will be greater than
n, so having the increment return undef on overflow doesn't help.
Trap values are a formalization of some existing concepts that we have
about LLVM IR, and give the optimizers a better basis for answering yes
to both questions above.
llvm-svn: 102140
arguments are handled with a new InlineFunctionInfo class. This
makes it easier to extend InlineFunction to return more info in the
future.
llvm-svn: 102137
define void @f3(void (i8*)* %__f) ssp {
entry:
call void %__f(i8* undef)
unreachable
}
define void @f4(i8* %this) ssp align 2 {
entry:
call void @f3(void (i8*)* @f2) ssp
ret void
}
The inliner is turning the indirect call to %__f into a direct
call to F2. Make the call graph more precise when this happens.
The inliner doesn't revisit call sites introduced by inlining,
so there isn't an easy way to test for this, but a more precise
callgraph is a good thing.
llvm-svn: 102131
