[LLVMdev] Iterator protocols

[Chris Lattner]

On May 13, 2008, at 4:09 PM, Gordon Henriksen wrote:

> On May 13, 2008, at 18:28, Dan Gohman wrote:
>
>> On May 12, 2008, at 6:49 PM, Talin wrote:
>>
>>> So the question is, what's the trade-off. In most languages that
>>> support exceptions, you tend to think of exceptions as expensive
>>> operations that should only be thrown if something truly
>>> "exceptional" happens. OTOH, the Java case is also made worse by
>>> the fact that a large part of the time you'll be using the more
>>> expensive interface dispatching, rather than simple vtable
>>> dispatching.
>>
>> How dynamic is your language? Is it possible that the resolution of
>> the hasNext method could change as the loop executes? If not, it
>> would be neat to find a way to resolve the hasNext callee once,
>> before the loop, and then just make a simple call on each iteration.
>
> I wonder if it would be worthwhile to have a flag on loads to mark
> them as immutable. A flag from the source language stating "this load
> never aliases any subsequent store." A majority of loads in functional
> languages are of this nature. I could see a number of benefits:
>
> • Duplicate loads could be RAUW'd based solely on SSA properties.
> • load / store alias analysis could be short-circuited for such loads.
> • Codegen could remat such loads under register pressure.
> • Vtable lookups through loop-invariant SSA vars could trivially be
> shown to be themselves loop-invariant.

This is very interesting.  If there is a use-case that this sort of  
thing would strongly benefit, then we could add it.  We would want  
very strongly defined properties though.  Saying that no subsequent  
store aliases the load is probably sufficient.

> C++'s predilection for swizzling vtable pointers in constructors and
> destructors probably prevents it from being a useful facility for
> vtable lookups though. Short of a necessarily whole-program source-
> language interprocedural analysis proving safety. Sigh.

Right :( :(

-Chris