A question about bytecodes + unsigned load ./. add performace
Ulf.Zibis at gmx.de
Wed Jan 14 15:17:03 PST 2009
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 ?
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
> 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 ?
>> 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 ([]) 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
More information about the hotspot-dev