ciTypeFlow, osrs and jsr/ret

[Tom Rodriguez]

On Aug 26, 2009, at 6:26 PM, John Rose wrote:

> 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.

We specifically disallow osr's into blocks with live jsr's. ciTypeFlow  
checks for this and bails out if it occurs.  One way to look at this  
is that any local which contains an address at an OSR entry actually  
must be dead and should be treated as such.  That still doesn't  
address the issue that the types of other locals in the OSR entry  
aren't really right.  I'm not really sure why we'd ever need to clone  
a block that was a suitable OSR entry point.  We could never reach  
that block with pending rets so why would it need to be cloned?

tom

>
> 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