[LLVMdev] CFG modifcations and code gen

[Villmow, Micah]

Chris,

 I took a look at AnalyzeBranch and I don't see how it can solve my
problem. The issue itself isn't with branching, as I can handle branches
fairly well in my custom pass(see the before and after dot files
attached). I can take a bunch of branches and construct high level
control flow for my backend since I have no ability to do goto/jump,
only whileloop and ifs. So analyzing the branch's isn't the problem. The
problem comes with emit'ing the code. Even though I've renumbered the
blocks and re-ordered the CFG into a more sane control flow. The code
emitter still processes the blocks in the old order. So instead of going
from 0-5, it prints out the instructions in the order, 0, 1, 2, 5, 3, 4.
This is the order that the old CFG is in, not the new one after this
pass is done.

I've added this analysis pass as a PreEmitPass, is this the correct
location to implement this? Or should I be implementing it earlier?
Later?

 

 

Thanks for any advice,

 

________________________________

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Chris Lattner
Sent: Tuesday, October 14, 2008 9:50 AM
To: LLVM Developers Mailing List
Subject: Re: [LLVMdev] CFG modifcations and code gen

 

 

On Oct 14, 2008, at 9:16 AM, Villmow, Micah wrote:





But, the branch folding pass, or whatever passes are supposed to reorder
the blocks based on the CFG, are not doing so in this case. Otherwise
there is no way that blocks 2 and 4 should be printing out before blocks
3 & 5. Renumber blocks just seems to reorder the values based on their
pre-set block number, but when the CFG is modified these number should
modified also to follow the new ordering, which is not occurring.

 

Did you implement TargetInstrInfo::AnalyzeBranch for your target?  Check
out the large comment above it in TargetInstrInfo.h

 

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081014/8b38eb37/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: before_control_flow_pass.dot
Type: application/octet-stream
Size: 2896 bytes
Desc: before_control_flow_pass.dot
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081014/8b38eb37/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: after_control_flow_pass.dot
Type: application/octet-stream
Size: 2455 bytes
Desc: after_control_flow_pass.dot
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081014/8b38eb37/attachment-0001.obj>