bytecode files when compiling 176.gcc, but more importantly will make it
easier to eliminate CPR's in the future (no new .bc revision will be
required to support them)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10884 91177308-0d34-0410-b5e6-96231b3b80d8
of forcing them to go through ConstantPointerRef's. This allows bytecode
files to mirror .ll files, allows more efficient encoding, and makes it easier
to eventually eliminate CPR's.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10883 91177308-0d34-0410-b5e6-96231b3b80d8
returning error codes. Because they don't return an error code, they can
return the value read, which simplifies the code and makes the reader more
efficient (yaay!).
Also eliminate the special case code for little endian machines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10871 91177308-0d34-0410-b5e6-96231b3b80d8
intended to save size (and does on small programs), but on big programs it
actually increases the size of the program slightly. The deal is that many
functions end up using the characters that the string contained, and the
characters are no longer in the global constant table, so they have to be
emitted in function specific constant pools.
This pessimization will be fixed in subsequent patches.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10864 91177308-0d34-0410-b5e6-96231b3b80d8
Since this really only makes sense for these two, change hte instance variable
to reflect whether we are writing a bytecode file or not. This makes it
reasonable to add bcwriter specific stuff to it as necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10837 91177308-0d34-0410-b5e6-96231b3b80d8
The first change (which is disabled) compactifies all of the function constant
pools into the global constant pool, in an attempt to reduce the amount of
duplication and overhead. Unfortunately, as the comment indicates, this is
not yet a win, so it is disabled.
The second change sorts the typeid's so that those types that can be used
by instructions in the program appear earlier in the table than those that
cannot (such as structures and arrays). This causes the instructions to
be able to use the dense encoding more often, saving about 5K on 254.gap.
This is only a .65% savings though, unfortunately. :(
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10754 91177308-0d34-0410-b5e6-96231b3b80d8
occurs when the symbol table for a module has been stripped, making all of the
function local symbols go away.
This saves 6728 bytes in the stripped bytecode file of 254.gap (which obviously
has 841 functions), which isn't a ton, but helps and was easy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10750 91177308-0d34-0410-b5e6-96231b3b80d8
* Refactor reader stuff out of include/llvm/Bytecode/Primitives.h. This is
internal implementation details for the reader, not public interfaces!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10739 91177308-0d34-0410-b5e6-96231b3b80d8
Modified ReadArchiveBuffer() so that it dynamically allocates the
std::string object used to hold the bytecode object file's name. This is
necessary because it is passed by reference to the new Module that is
allocated to represent the bytecode object, and previously we were
using a std::string that disappeared on function exit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10565 91177308-0d34-0410-b5e6-96231b3b80d8
beginning of the archive member data as an argument.
Get rid of ParseLongFilenameSection(), which is dead.
In ReadArchiveBuffer(), implement support for 4.4BSD/MacOSX long filenames.
This is kind of invasive, because they prepend the long filename to the archive
member data, and then lie about the size. So we have to keep track of the real
size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10392 91177308-0d34-0410-b5e6-96231b3b80d8
each basic block in function. Instead, just emit a stream of instructions,
chopping up basic blocks based on when we find terminator instructions. This
saves a fairly substantial chunk of bytecode space. In stripped, sample
cases, for example, we get this reduction in size:
197.parser: 163036 -> 137180: 18.8% reduction
254.gap : 844936 -> 689392: 22.6%
255.vortex: 621724 -> 528444: 17.7%
...
Not bad for something this simple. :) Note that this doesn't require a new
bytecode version number at all, though version 1.1 should not need to support
the old format.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10280 91177308-0d34-0410-b5e6-96231b3b80d8
* Strength reduce several data structures which were left over from the
"bad old days"
* Minor efficiency improvements
* Major efficiency improvement: In BytecodeParser::insertValue, do not allocate
a new ValueTab entry just because some value exists with a large type. This
dramatically reduces the number of allocations/deallocations performed by the
bytecode reader, and speeds up parsing of Kimwitu++ from 34s to 17s. This is
to help address PR127
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10085 91177308-0d34-0410-b5e6-96231b3b80d8
Correctly parse the Long Filename section of the archive.
When reading in archive members, set their ModuleIDs to
"ARCHIVENAME(MEMBERNAME)", as is traditional.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10043 91177308-0d34-0410-b5e6-96231b3b80d8
