idf_iterator and MachineFunctions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

idf_iterator and MachineFunctions

Lang Hames
Hi,

I need to do an inverse-depth-first iteration over the basic blocks in
a machine function (i.e. starting from the last block and following
predecessor edges) for a liveness analysis I'm writing.

idf_iterator seems like it's almost the class I need, but it starts at
the first block in the function at present, rather than the last one
(because of the specialisiation of GraphTraits for
Inverse<MachineFunction*> - getEntryNode returns mf->front()). That
seems odd to me - you can only ever get to the first block with it
(incrementing the iterator once yields idf_end(mf), and there's no
decrement operation).

Is this behaviour intentional?

If it is I'll need to write some inverse iteration functions myself.
Is there a recommended way to find the final block (the one with
successors={}) in a machine function? (will mf->back() always return
it?)


Thanks,

Lang.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: idf_iterator and MachineFunctions

Gordon Henriksen-3
On 2007-03-18, at 03:22, Lang Hames wrote:

Is there a recommended way to find the final block (the one with successors={}) in a machine function?


This isn't a property of the CFG in the general case. However, the UnifyFunctionExitNodes transformation/analysis provides it. From getAnalysis<UnifyFunctionExitNodes>().getReturnBlock(), you can visit the basic block predecessors recursively.

— Gordon


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: idf_iterator and MachineFunctions

Gordon Henriksen-3
On 2007-03-18, at 09:54, Gordon Henriksen wrote:

> On 2007-03-18, at 03:22, Lang Hames wrote:
>
>> Is there a recommended way to find the final block (the one with  
>> successors={}) in a machine function?
>
> This isn't a property of the CFG in the general case. However, the  
> UnifyFunctionExitNodes transformation/analysis provides it. From  
> getAnalysis<UnifyFunctionExitNodes>().getReturnBlock(), you can  
> visit the basic block predecessors recursively.

Oh, MachineBB. Sorry; don't have an answer for you.

— Gordon


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: idf_iterator and MachineFunctions

Chris Lattner
In reply to this post by Lang Hames
On Sun, 18 Mar 2007, Lang Hames wrote:
> I need to do an inverse-depth-first iteration over the basic blocks in
> a machine function (i.e. starting from the last block and following
> predecessor edges) for a liveness analysis I'm writing.

As Gordon mentioned, there isn't a trivial way to do this, as there isn't
a single exit node in the MBB CFG.

> idf_iterator seems like it's almost the class I need, but it starts at
> the first block in the function at present, rather than the last one
> (because of the specialisiation of GraphTraits for
> Inverse<MachineFunction*> - getEntryNode returns mf->front()). That
> seems odd to me - you can only ever get to the first block with it
> (incrementing the iterator once yields idf_end(mf), and there's no
> decrement operation).

That seems odd to me too.  It sounds like Inverse<MF*> should be removed.

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: idf_iterator and MachineFunctions

Lang Hames
> That seems odd to me too.  It sounds like Inverse<MF*> should be removed.

Alright. Thanks for the feedback.

Cheers,
Lang.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev