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
Eventually this pass will provide substantially better code in the interim between when we
have a crappy isel and nice isel. Unfortunately doing so requires fixing the backend to
actually SUPPORT all of the fancy addressing modes that we now generate, and writing a DCE
pass for machine code. Each of these is a fairly substantial job, so this will remain disabled
for the immediate future. :(
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10276 91177308-0d34-0410-b5e6-96231b3b80d8
folding of instructions into addressing modes. This creates lots of dead
instructions, which are currently not deleted. It also creates a lot of
instructions that the X86 backend currently cannot handle. :(
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10275 91177308-0d34-0410-b5e6-96231b3b80d8
bug where spill instructions were added to the next basic block
instead of the end of the current one if the instruction that required
the spill was the last in the block.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10272 91177308-0d34-0410-b5e6-96231b3b80d8
allow unaligned loads, that is probably the problem I've been seeing in numerous
SPARC test cases failing. X86, on the other hand, just slows down unaligned
accesses, since it must make 2 aligned accesses for each unaligned one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10266 91177308-0d34-0410-b5e6-96231b3b80d8
tested automatically, so it is practically useless. However, it seemed silly to throw
away my testcase, so here it is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10253 91177308-0d34-0410-b5e6-96231b3b80d8
* Finegrainify namespacification of Linker.cpp
* If linking a library in fails, do not STOP LINKING IN LIBRARIES AND
CONTINUE ANYWAY! Instead, just output the warning, and keep going. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10249 91177308-0d34-0410-b5e6-96231b3b80d8
* stdlib and friends are system headers
* 'long long' is the type that consistently turns into the LLVM 'long' type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10241 91177308-0d34-0410-b5e6-96231b3b80d8
Explained that function return types cannot be aggregate types.
Explained that functions with the same name but different type signatures
are considered to be different functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10230 91177308-0d34-0410-b5e6-96231b3b80d8
