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

[Ulf Zibis]

Hi Tom, yes, it's some days ago.

Can you please outline "IR" for me?

-Ulf


Am 15.01.2009 01:11, Tom Rodriguez schrieb:
>
> 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
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>