[LLVMdev] How to check for "SPARC code generation" in MachineBasicBlock.cpp?
clattner at apple.com
Mon Feb 8 09:57:32 PST 2010
On Feb 8, 2010, at 12:37 AM, Nathan Keynes wrote:
> Firstly, the BNE/BA pair should be reduced to a BE (I assume this is
> the responsibility of AnalyzeBranch and friends that you mention).
Right. Implementing AnalyzeBranch will allow a bunch of block layout
and branch optimizations to happen.
> However I still wouldn't have expected that to result in the label
> being omitted (assuming multiple branches are legal in an MBB). It
> appears that the branch delay-slots are specifically to blame here
Yes, most certainly.
> - the above BB#315 immediately prior to output is
> BB#7: derived from LLVM BB %bb
> Live Ins: %L1 %L0 %L3 %L2 %L4
> Predecessors according to CFG: BB#6
> %L5<def> = SETHIi 1856
> %L6<def> = ORri %G0, 1
> %L3<def> = SLLrr %L6<kill>, %L3<kill>
> %L5<def> = ORri %L5<kill>, 1
> %L3<def> = ANDrr %L3<kill>, %L5<kill>
> %L3<def,dead> = SUBCCri %L3<kill>, 0, %ICC<imp-def>
> BCOND <BB#8>, 9, %ICC<imp-use,kill>
> BA <BB#68>
> which leads MachineBasicBlock::isOnlyReachableByFallthrough() to
> return TRUE for BB#8, since the final NOP is not a 'barrier
> instruction', and so the label is skipped.
Yep, that sounds like the problem.
> So I guess the question I have is, are MBBs like BB#7 above legal,
Funny question :). When I was working on the sparc backend, it was
unclear how best to represent delay slots. The approach I took was to
pretend that they didn't exist for most of the compiler backend, then
have DelaySlotFiller create them right before the asmprinter ran. The
idea was to eventually extend DelaySlotFiller to put something better
than a nop in them :)
This all works as long as the asmprinter is a simple pass through that
doesn't look at the code, which isOnlyReachableByFallthrough violates.
As far as a proposed solution, since asmprinter is the only user of
isOnlyReachableByFallthrough, I'd recommend moving
isOnlyReachableByFallthrough to be
AsmPrinter::IsBlockOnlyReachableByFallthrough. Then you can make it
virtual, and have the sparc backend provide its own implementation of
it (which might as well just return false all the time).
> and if so would something like
> BCOND cond1, BB#8
> BCOND cond2, BB#57
> also be legal - ie BB7 contains both a branch and a fallthrough to
> the same successor block?
That form is legal, but not desirable because AnalyzeBranch isn't able
to model it. This will cause a bunch of useful optimizations to get
More information about the llvm-dev