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
both cases they are looking for non-external variables/functions that do
not have internal linkage. Using "!isExternal()" is a little more
understandable than "hasInitializer()"
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20155 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
table for archives in common cases, and prevents trying to resolve a
external reference with an internal reference. This shrinks the libpython.a
symbol table from 126302 to 19770 bytes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20151 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
Remove unix specific code (use of errno and read) from the reader.
Thanks to Jeff Cohen for pointing this out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@19081 91177308-0d34-0410-b5e6-96231b3b80d8
Use sys::MappedFile instead of ReadFileIntoAddressSpace and
UnmapFileFromAddressSpace. sys::MappedFile has the nice property that it
cleans up after itself so exception handling can be removed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@18902 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
This should fix the problem of not being able to link compressed LLVM
bytecode files from LLVM libraries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@17648 91177308-0d34-0410-b5e6-96231b3b80d8
end of files, breaking the CFE build. As a gross hack around this,
ignore any trailing garbage on bytecode files. Thanks to Brian for digging
in and identifying the problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@16525 91177308-0d34-0410-b5e6-96231b3b80d8
Move include/Config and include/Support into include/llvm/Config,
include/llvm/ADT and include/llvm/Support. From here on out, all LLVM
public header files must be under include/llvm/.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@16137 91177308-0d34-0410-b5e6-96231b3b80d8
- Rearrange output order to make more sense
- Make only the function level output count as "detailed"
- Output dump output directly to stream, don't buffer it.
- Fix counting of block sizes
- Implement new handlers for number of types, dependent libs, target triple
- Compute the size of block headers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@15985 91177308-0d34-0410-b5e6-96231b3b80d8
- Pass the output stream to the analyzer so it can write its output there
directly instead of buffering it.
- Don't pass a boolean to ParseBytecode because its not needed any more.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@15983 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the "processFunctions" boolean from ParseBytecode as it is no
longer needed. This is part of avoiding double reading of functions
when analyzing bytecode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@15982 91177308-0d34-0410-b5e6-96231b3b80d8
- provide the correct conversion for ModuleBlockID in read_block (a potential
bug but not actually exploited because reading module block ids doesn't
use read_block).
- install support for handleTypeList handler
- install support for handleDependentLibrary handler
- install support for handleTargetTriple handler
- clean up comments, output strings,
- ensure that processing function arguments doesn't SIGSEGV if one of the
arguments is a null pointer (yeah, it happened .. weird)
- prepare for version 5 bytecode by documenting what will change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@15981 91177308-0d34-0410-b5e6-96231b3b80d8
- File format version number bumped to 4
- Writer will now align nothing
- Reader now only expects alignment for version 3 or earlier
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@15875 91177308-0d34-0410-b5e6-96231b3b80d8
(At[3] << 24) is an int type and it is being coerced to uint64_t, it was
getting sign extended, causing us to get FFFFFFFFxxxxxxxx constants all of
the time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@15224 91177308-0d34-0410-b5e6-96231b3b80d8
