define void @f() {
...
call i32 @g()
...
}
define void @g() {
...
}
The hazards are:
- @f and @g have GC, but they differ GC. Inlining is invalid. This
may never occur.
- @f has no GC, but @g does. g's GC must be propagated to @f.
The other scenarios are safe:
- @f and @g have the same GC.
- @f and @g have no GC.
- @g has no GC.
This patch adds inliner checks for the former two scenarios.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45351 91177308-0d34-0410-b5e6-96231b3b80d8
function with GC.
This will catch the error when the inliner inlines a function with
GC into a caller with no GC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45350 91177308-0d34-0410-b5e6-96231b3b80d8
as on functions. Make it verify invokes and not just
ordinary calls. As a (desired) side-effect, it is no
longer legal to have call attributes on arguments that
are being passed to the varargs part of a varargs
function (llvm-as drops them on the floor anyway).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45286 91177308-0d34-0410-b5e6-96231b3b80d8
return attributes on the floor. In the case of a call
to a varargs function where the varargs arguments are
being removed, any call attributes on those arguments
need to be dropped. I didn't do this because I plan to
make it illegal to have such attributes (see next patch).
With this change, compiling the gcc filter2 eh test at -O0
and then running opt -std-compile-opts on it results in
a correctly working program (compiling at -O1 or higher
results in the test failing due to a problem with how we
output eh info into the IR).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45285 91177308-0d34-0410-b5e6-96231b3b80d8
calls 'nounwind'. It is important for correct C++
exception handling that nounwind markings do not get
lost, so this transformation is actually needed for
correctness.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45218 91177308-0d34-0410-b5e6-96231b3b80d8
how to lower them (with no attempt made to be
efficient, since they should only occur for
unoptimized code).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45108 91177308-0d34-0410-b5e6-96231b3b80d8
calls. Remove special casing of inline asm from the
inliner. There is a potential problem: the verifier
rejects invokes of inline asm (not sure why). If an
asm call is not marked "nounwind" in some .ll, and
instcombine is not run, but the inliner is run, then
an illegal module will be created. This is bad but
I'm not sure what the best approach is. I'm tempted
to remove the check in the verifier...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45073 91177308-0d34-0410-b5e6-96231b3b80d8
endianness of the target not of the host. Done by the
simple expedient of reversing bytes for primitive types
if the host and target endianness don't match. This is
correct for integer and pointer types. I don't know if
it is correct for floating point types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45039 91177308-0d34-0410-b5e6-96231b3b80d8
SelectionDAG::getConstant, in the same way as vector floating-point
constants. This allows the legalize expansion code for @llvm.ctpop and
friends to be usable with vector types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44954 91177308-0d34-0410-b5e6-96231b3b80d8
2. Using zero-extended value of Scale and unsigned division is safe provided
that Scale doesn't have the sign bit set.
Previously these 2 instructions:
%p = bitcast [100 x {i8,i8,i8}]* %x to i8*
%q = getelementptr i8* %p, i32 -4
were combined into:
%q = getelementptr [100 x { i8, i8, i8 }]* %x, i32 0,
i32 1431655764, i32 0
what was incorrect.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44936 91177308-0d34-0410-b5e6-96231b3b80d8
