PHI node entries from multiple outside-the-region blocks. This also fixes
extraction of the entry block in a function. Yaay.
This has successfully block extracted all (but one) block from the score_move
function in obsequi (out of 33). Hrm, I wonder which block the bug is in. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13489 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a stub for the severSplitPHINodes which will allow us to bbextract
bb's with PHI nodes in them soon.
* Remove unused arguments from findInputsOutputs
* Dramatically simplify the code in findInputsOutputs. In particular,
nothing really cares whether or not a PHI node is using something.
* Move moveCodeToFunction to after emitCallAndSwitchStatement as that's the
order they get called.
* Fix a bug where we would code extract a region that included a call to
vastart. Like 'alloca', calls to vastart must stay in the function that
they are defined in.
* Add some comments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13482 91177308-0d34-0410-b5e6-96231b3b80d8
from the extracted region. If the return has 0 or 1 exit blocks, the new
function returns void. If it has 2 exits, it returns bool, otherwise it
returns a ushort as before.
This allows us to use a conditional branch instruction when there are two
exit blocks, as often happens during block extraction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13481 91177308-0d34-0410-b5e6-96231b3b80d8
1. Get rid of the silly abort block. When doing bb extraction, we get one
abort block for every block extracted, which is kinda annoying.
2. If the switch ends up having a single destination, turn it into an
unconditional branch.
I would like to add support for conditional branches, but to do this we will
want to have the function return a bool instead of a ushort.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13478 91177308-0d34-0410-b5e6-96231b3b80d8
in the basic block being processed. This fixes PhiElimination on kimwitu++
from taking 105s to taking a much more reasonable 0.6s (in a debug build).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13453 91177308-0d34-0410-b5e6-96231b3b80d8
than before. Because this is the case, we can compute the first non-phi
instruction once when de-phi'ing a block. This shaves ~4s off of
phielimination of _Z7yyparsev in kimwitu++ from 109s -> 105s. There are
still much more important gains to come.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13452 91177308-0d34-0410-b5e6-96231b3b80d8
compiling things like 'add long %X, 1'. The problem is that we were switching
the order of the operands for longs even though we can't fold them yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13451 91177308-0d34-0410-b5e6-96231b3b80d8
when we see a read of a register. This is important in cases like:
AL = ...
AH = ...
= AX
The read of AX must make both the AL and AH defs live until the use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13444 91177308-0d34-0410-b5e6-96231b3b80d8
FindUsedTypes manipulation stuff out to be a seperate pass, and make the
main CWriter be a function pass now!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13435 91177308-0d34-0410-b5e6-96231b3b80d8
Flesh out the SetCC support... which currently ends in a little bit
of unfinished code (which is probably completely hilarious) for
generating the condition value splitting the basic block up into 4
blocks, like this (clearly a better API is needed for this!):
BB
cond. branch
/ / R1=1 R2=0
\ /
\ /
R=phi(R1,R2)
Other minor edits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13423 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for branches (based loosely on X86/InstSelectSimple).
Add support for not visiting phi nodes in the first pass.
Add support for loading bools.
Flesh out support for stores.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13418 91177308-0d34-0410-b5e6-96231b3b80d8
%tmp.0 = getelementptr [50 x sbyte]* %ar, uint 0, int 5 ; <sbyte*> [#uses=2]
%tmp.7 = getelementptr sbyte* %tmp.0, int 8 ; <sbyte*> [#uses=1]
together. This patch actually allows us to simplify and generalize the code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13415 91177308-0d34-0410-b5e6-96231b3b80d8
Disable the code that copies long constants to registers - it looks fishy.
Implement some simple casts: integral, smaller than longs, and equal-width
or narrowing only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13413 91177308-0d34-0410-b5e6-96231b3b80d8
When looking at getelementptr instructions, make sure to use a forwarded
type. We want to do this because a DerivedType may drop its uses and then
refine its users, who may then use another user who hasn't been refined yet.
By getting the forwarded type, we always ensure that we're looking at a
Type that isn't in a halfway refined state.
Now, I should be able to put this stuff in PATypeHandle, but it doesn't work
for some reason. This should do for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13386 91177308-0d34-0410-b5e6-96231b3b80d8
the debugging functions that call "dot". These fixed settings have
various problems: for example, the fixed size that is set in the graph
traits classes is not appropriate for turning the dot file into a PNG,
and if TrueType font rendering is being used, the 'Courier' TrueType font
may not be installed. It seems easy enough to specify these things on the
command line, anyhow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13366 91177308-0d34-0410-b5e6-96231b3b80d8
constant pool member's name.
This is intended to address Bug 333.
Also, fix an anachronistic usage of "M" as a parameter of type Function *.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13357 91177308-0d34-0410-b5e6-96231b3b80d8
fills in a ToolArgs vector in the AbstractInterpreter if it is set. This
ToolArgs vector is used to pass additional arguments to LLI and/or LLC.
This is intended to address Bug 40.
Also, make -debug-only=toolrunner work for the LLC and CBE
AbstractInterpreters.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13356 91177308-0d34-0410-b5e6-96231b3b80d8
use MachineBasicBlocks. To do this, we traverse the Machine CFG instead of
the LLVM CFG, which is also *MUCH* more efficient by having fewer levels of
indirections and mappings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13301 91177308-0d34-0410-b5e6-96231b3b80d8
is only used by a cast, and the casted type is the same size as the original
allocation, it would eliminate the cast by folding it into the allocation.
Unfortunately, it was placing the new allocation instruction right before
the cast, which could pull (for example) alloca instructions into the body
of a function. This turns statically allocatable allocas into expensive
dynamically allocated allocas, which is bad bad bad.
This fixes the problem by placing the new allocation instruction at the same
place the old one was, duh. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13289 91177308-0d34-0410-b5e6-96231b3b80d8
* Make contained ostream pointer, not reference
* Allow setting of that ostream via setStream()
class CachedWriter:
* setStream() in turn calls setStream() on the AssemblyWriter
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13247 91177308-0d34-0410-b5e6-96231b3b80d8
In InsertFPRegKills(), just check the MachineBasicBlock for successors
instead of its corresponding BasicBlock.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13213 91177308-0d34-0410-b5e6-96231b3b80d8
Include SparcV9RegisterInfo.h.
Add a getRegisterInfo() accessor and SparcV9RegisterInfo instance, just like
on the X86 target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13146 91177308-0d34-0410-b5e6-96231b3b80d8
functions for now). This automatically turns on the printing of machine
registers using their own real names, instead of goofy things like %mreg(42),
and allows us to migrate code incrementally to the new interface as we see fit.
The register file description it uses is hand-written, so that the register
numbers will match the ones that the SparcV9 target already uses.
Perhaps someday we'll tablegen it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13145 91177308-0d34-0410-b5e6-96231b3b80d8
This prepares us to be able to de-virtualize and de-abstract it, and
take the register allocator bits out and move them into the register allocator
proper...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13127 91177308-0d34-0410-b5e6-96231b3b80d8
documentation that this module needs to be made independent of the
register file description of the current target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13125 91177308-0d34-0410-b5e6-96231b3b80d8
because 1) the first instruction might not be a call site, and
2) CS and SF.Caller were not getting set to point to the new call site
anyway (resulting in a crash on e.g. call %llvm.memset).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13122 91177308-0d34-0410-b5e6-96231b3b80d8
the Module. The default behavior keeps functionality as before: the chosen
function is the one that remains.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13111 91177308-0d34-0410-b5e6-96231b3b80d8
loop. This eliminates the extra add from the previous case, but it's
not clear that this will be a performance win overall. Tommorows test
results will tell. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13103 91177308-0d34-0410-b5e6-96231b3b80d8
over its USES. If it's dead it doesn't have any uses! :)
Thanks to the fabulous and mysterious Bill Wendling for pointing this out. :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13102 91177308-0d34-0410-b5e6-96231b3b80d8
Eventually it would be nice if CallGraph maintained an ilist of CallGraphNode's instead
of a vector of pointers to them, but today is not that day.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13100 91177308-0d34-0410-b5e6-96231b3b80d8
of IntCC, FloatCC, and Special types.
Make SparcV9RegInfo::getRegClassIDOfRegType() return the right answer
if you ask for the class corresponding to SpecialRegType.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13095 91177308-0d34-0410-b5e6-96231b3b80d8
the name of %fsr (as the comment in SparcV9RegClassInfo.h used to suggest)
you would walk off the end of the FloatCCRegName array.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13070 91177308-0d34-0410-b5e6-96231b3b80d8
structure to being dynamically computed on demand. This makes updating
loop information MUCH easier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13045 91177308-0d34-0410-b5e6-96231b3b80d8
that the exit block of the loop becomes the new entry block of the function.
This was causing a verifier assertion on 252.eon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13039 91177308-0d34-0410-b5e6-96231b3b80d8
block. The primary motivation for doing this is that we can now unroll nested loops.
This makes a pretty big difference in some cases. For example, in 183.equake,
we are now beating the native compiler with the CBE, and we are a lot closer
with LLC.
I'm now going to play around a bit with the unroll factor and see what effect
it really has.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13034 91177308-0d34-0410-b5e6-96231b3b80d8
limited. Even in it's extremely simple state (it can only *fully* unroll single
basic block loops that execute a constant number of times), it already helps improve
performance a LOT on some benchmarks, particularly with the native code generators.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13028 91177308-0d34-0410-b5e6-96231b3b80d8
operations. This allows us to compile this testcase:
int main() {
int h = 1;
do h = 3 * h + 1; while (h <= 256);
printf("%d\n", h);
return 0;
}
into this:
int %main() {
entry:
call void %__main( )
%tmp.6 = call int (sbyte*, ...)* %printf( sbyte* getelementptr ([4 x sbyte]* %.str_1, long 0, long 0), int 364 ) ; <int> [#uses=0]
ret int 0
}
This testcase was taken directly from 256.bzip2, believe it or not.
This code is not as general as I would like. Next up is to refactor it
a bit to handle more cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13019 91177308-0d34-0410-b5e6-96231b3b80d8