[llvm] r175382 - Add support for updating the LiveIntervals of registers used by 'exotic'

David Blaikie dblaikie at gmail.com
Sat Feb 16 19:21:53 PST 2013


On Sat, Feb 16, 2013 at 7:06 PM, Chandler Carruth <chandlerc at google.com>wrote:

>
> On Sat, Feb 16, 2013 at 6:40 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:
>
>> >> I think it is too confusing to use reverse_iterators in an API. Can't
>> you keep that detail internal to the function? Better yet, just use -- to
>> move backwards.
>> >
>> > I originally wrote it that way, but it felt awkward since we are
>> iterating backwards over an interval (A, B] not forward over an interval
>> [A, B). I guess you are just suggesting that I do the conversion from
>> left-open to right-open intervals in the function itself.
>>
>> Yes, but even then I usually just use:
>>
>> for (iterator I = End; I != Begin;) {
>>   --I;
>>   use(I);
>> }
>>
>
> This prevents ever using an algorithm on the range, or (eventually)
> range-based for loops. I think that is the primary benefit of writing the
> above in terms of reverse iterators. It confused me the first time I saw
> it, but now I find the reverse iterator pattern quite friendly.
>
> We could also help it by providing:
>
> iterator RBegin, REnd;
> tie(RBegin, REnd) = reverse_iterator_pair(Begin, End);
>
>
>>
>> It's less confusing IMHO.
>>
>> Note that dereferencing a MachineBasicBlock::reverse_iterator causes it
>> to scan the whole bundle it is pointing to:
>>
>>   reference operator*() const {__t = current; return *--__t;}
>
>
> Regardless of the above, this seems bad. Couldn't this be factored into
> the increment step (much as I assume the decrement step in forward
> iterators does?)
>

(I might not have enough context here - if so, sorry)

It's possible that this cannot be factored into the increment step since
you don't know at increment time whether or not the point you're moving to
is dereferencable (because you could be moving to the end). When you
decrement a forward iterator you know that the point you're moving to is
valid, since there's no "off the beginning  point you can reach.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130216/6d911ad8/attachment.html>


More information about the llvm-commits mailing list