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
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
Am Freitag, den 16.05.2008, 06:54 -0700 schrieb Chris Lattner:> On May 13, 2008, at 4:09 PM, Gordon Henriksen wrote: > > > On May 13, 2008, at 18:28, Dan Gohman wrote: > > > > 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.Any tight loop that uses a virtual function. That's interesting for languages where functions are virtual by default. (I think OO language designers tend to avoid nonvirtual functions in general.) Note that functional language tend to have the moral equivalent of virtual functions, too, but I don't know how strong the effect would be. Regards, Jo