[LLVMdev] An unexpected behavior in RegionInfo's block_iterator

[Paul Vario]

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

> On 03/05/2014 01:01, Paul Vario wrote:
>
>> 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()).
>>
>
> Why would you need such an iterator? The exit is not part of the region,
> so I am slightly surprised you expect it to be enumerated.
>
> Tobias
>
Had regioninfo been designed so that the region exit to be integral part of
a region, then there would be an iterator that enumerates up until exit ...
is what I was trying to say. You're totally right, under the current
design, there wouldn't be no need for such a iterator.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140502/c0e5cbf8/attachment.html>