[LLVMdev] Iterator protocols

[Gordon Henriksen]

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.

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.

— Gordon