[LLVMdev] An unexpected behavior in RegionInfo's block_iterator

[Paul Vario]

On Fri, May 2, 2014 at 5:30 PM, Tobias Grosser <tobias at grosser.es> wrote:

> On 03/05/2014 00:15, Paul Vario wrote:
>
>> Hi Tobias,
>>
>>       Thanks so much for the quick response. Your approach fixes the
>> issue.
>>       On a bigger context, would it make more sense to make the region
>> exit
>> part of the region? For example, a while loop gets lowered down to LLVM IR
>> contains while.cond, while.body and while.end. If one tries to use
>> RegionInfo as a substitute for structural analysis, she might think
>> while.end should belong to the region/structure ... is it necessary to
>> exclude the exit from being part of the region or both ways are equally
>> correct in terms of uniquely representing regions?
>>
>
> The region provides both the exiting blocks as well as the exit block. So
> you should have all you need, no?
>
Yes, the region interface suffices all my needs. It just does not contain
an "iterator" that can iterate all the basic blocks
in the region plus the exit at once. What I usually do, under this kind of
situation, is to define a std::vector of basicblocks,
push all the basic blocks in the region using block_iterator in a for loop.
And then, at the end, push_back(region->getExit()).


>
> An example, where it is beneficial to use the block after the region as to
> define a region is the following:
>
>     IF-1
>    /    \
>   |    IF-2
>   |   /   \
>   |   |   |
>    \  |  /
>     \ | /
>      \|/
>      END
>
> Here, we would like to model two regions IF-1 => END and IF-2 => END. The
> first region contains IF-1 and IF-2, the second one just IF-2. Obviously,
> neither of these regions has a single exit edge, but for both it is
> possible to create a single exit edge by introducing two
> new basic blocks on the outgoing edges of each region.
>
> Cheers,
> Tobias
>
Got it! Thanks for the example.

Best,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140502/d6b5c0bf/attachment.html>