ciTypeFlow, osrs and jsr/ret

[John Rose]

On Aug 25, 2009, at 1:53 PM, Tom Rodriguez wrote:

> My question is which version of the block should ciTypeFlow consider  
> to be the canonical one suitable for use by the parser?  It seems  
> like there's a conflict between the cloning for jsr/ret and  
> producing a canonical version suitable for the entry point.

Yes, that's a conflict.  The higher_equal assert seems to be saying "I  
expect to be running an OSR entry point state that has a return  
address set to 537 in local 21, but you are telling me that any old  
raw pointer might be in that local 21might contain any old address."   
That latter assertion is reasonable for an OSR entry point, since the  
interpreter state applies equally to all legal values of local 21, but  
the compiled state (apparently) applies only to the value 537.  It's  
OSR-ing into a finally block, perhaps.

I'm probably missing a bit here, but it seems to me that the block- 
splitting performed by ciTypeFlow is going to produce a bunch of  
splits for a give bytecoded block, but none of those splits is going  
to be suitable as an OSR entry point.  Instead, there needs to be some  
sort of decision tree at the OSR entry point to pick which block is  
going to be used, based on the contents of the locals.

I have a vague recollection that we refuse to create OSR entry points  
for some cases like this.  Maybe the bug is we're trying to do  
something that's impossible (without the as-yet-uncreated decision  
tree mentioned above).

-- John