A question about bytecodes + unsigned load ./. add performace

[Ulf Zibis]

Tom, thanks for your answer.

Hm, that would mean, (inByte & 0xFF) would be good for server VM, and 
bad for client VM. For client VM (inByte + 0x80) would be better.
Which to give the precedence ?

-Ulf


Am 13.01.2009 22:57, Tom Rodriguez schrieb:
> The client VM doesn't have any optimizations around folding unsigned 
> idioms into unsigned loads.  They wouldn't be that hard for someone to 
> add.
>
> tom
>
> On Jan 12, 2009, at 6:08 PM, Ulf Zibis wrote:
>
>> Wow, these are good news.  :-)
>>
>> So is there a chance, to implement this behaviour in trunk, so we 
>> could get rid of the +128 trick ?
>> Is it also available for -client VM ?
>>
>> -Ulf
>>
>>
>> Am 13.01.2009 02:39, John Rose schrieb:
>>> On Jan 12, 2009, at 1:52 PM, Tom Rodriguez wrote:
>>>
>>>> The ideal for the simple example is something like (StoreC mem2 
>>>> addr2 (AndI (LoadB mem1 addr1) (ConI 0xff))).  The code above will 
>>>> break the match at the load, forcing the value into a register.  
>>>> It's seem like an excessively strong cutout but I'm not sure how to 
>>>> phrase it better, particularly since I don't know what exactly what 
>>>> problem it designed to eliminate.  I believe it's probably the 
>>>> anti-dep issue but without a concrete failure it's hard to know 
>>>> what exactly it should look like.
>>>
>>> That sounds plausible.  In general, if a node has a unique user, it 
>>> can be pulled into one of the little spanning trees that the matcher 
>>> places over the ideal DAG.  The graph dump Christian sent shows that 
>>> the LoadB has just one user ([[141]]) which means the matcher should 
>>> be able to group the LoadB with the AndI (and transform to loadUB), 
>>> unless there's something else going on, like the anti-deps you mention.
>>>
>>> -- John
>>>
>>>
>>
>
>