.bc file if they are supposed to be implicit. This is cool, except that it
checked *after* constant expr folding: improving constant expr folding could
cause the .bc reader to assert out on old .bc files. Move the check so that
it checks all simple constants, but no constantexprs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@27480 91177308-0d34-0410-b5e6-96231b3b80d8
bytecode reading. This code is crufty, the result of much hacking to get things
working correctly. Cleanup patches will follow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25682 91177308-0d34-0410-b5e6-96231b3b80d8
Don't try to be smart about fixing intrinsic functions when they're read
in, just fix them after the module is read when all names are resolved.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25539 91177308-0d34-0410-b5e6-96231b3b80d8
boolean flag if we read a function prototype that needs upgrading.
2. Don't upgrade the CallInst instruction until after its been inserted
into the basic block, and only if we know that we have seen an
upgraded intrinsic function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25448 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is an incremental step towards supporting a flat symbol table.
It de-overloads the intrinsic functions by providing type-specific intrinsics
and arranging for automatically upgrading from the old overloaded name to
the new non-overloaded name. Specifically:
llvm.isunordered -> llvm.isunordered.f32, llvm.isunordered.f64
llvm.sqrt -> llvm.sqrt.f32, llvm.sqrt.f64
llvm.ctpop -> llvm.ctpop.i8, llvm.ctpop.i16, llvm.ctpop.i32, llvm.ctpop.i64
llvm.ctlz -> llvm.ctlz.i8, llvm.ctlz.i16, llvm.ctlz.i32, llvm.ctlz.i64
llvm.cttz -> llvm.cttz.i8, llvm.cttz.i16, llvm.cttz.i32, llvm.cttz.i64
New code should not use the overloaded intrinsic names. Warnings will be
emitted if they are used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@25366 91177308-0d34-0410-b5e6-96231b3b80d8
pointer marking the end of the list, the zero *must* be cast to the pointer
type. An un-cast zero is a 32-bit int, and at least on x86_64, gcc will
not extend the zero to 64 bits, thus allowing the upper 32 bits to be
random junk.
The new END_WITH_NULL macro may be used to annotate a such a function
so that GCC (version 4 or newer) will detect the use of un-casted zero
at compile time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23888 91177308-0d34-0410-b5e6-96231b3b80d8
lookups instead of linear time lookups. This speeds up bc parsing of a
large file from
137.834u 118.256s 4:27.96
to
132.611u 114.436s 4:08.53
with a release build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@23611 91177308-0d34-0410-b5e6-96231b3b80d8
using Function::arg_{iterator|begin|end}. Likewise Module::g* -> Module::global_*.
This patch is contributed by Gabor Greif, thanks!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20597 91177308-0d34-0410-b5e6-96231b3b80d8
Otherwise, clients who call ParseAllFunctionBodies will attempt to parse
the function bodies twice, which is (uh) very very bad (tm).
This fixes gccld on python.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20152 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM make the very reasonable assumption that constant expressions will
have at least one operand! :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@19943 91177308-0d34-0410-b5e6-96231b3b80d8
a different algorithm that was extremely inefficient for instructions with
many operands.
This reduces the time of this code snippet from .23s for 176.gcc to 0.03s
in a debug build, which speeds up total llvm-dis time just barely.
It's more of a code cleanup than a speedup.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@18685 91177308-0d34-0410-b5e6-96231b3b80d8
Chris Lattner