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

[Tom Rodriguez]

On Jan 14, 2009, at 3:17 PM, Ulf Zibis wrote:

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

Unfortunately neither works with client, which leads to a simple  
answer to your question.  The usage of addressing modes isn't exposed  
in the IR so there's no constant folding between constants in the code  
and constants in the address.  Client started its life as a simple  
template like JIT and it's come a long way since then but the high  
level and low level IR could use some revisiting.

tom

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