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

John Rose John.Rose at Sun.COM
Thu Jan 15 12:51:49 PST 2009


The problem of delaying optimizations until the matcher is the  
optimizer (esp. loop opts) can push the graph into an unrecognizable  
shape.  If control inputs are preventing the matcher's merge-up,  
perhaps they are fallout from loop opts or some other CFG change.

Maybe we should bite the bullet and introduce an ideal node LoadUB  
for read-unsigned-8 (and maybe LoadUI for read-unsigned-32? -- we  
have LoadC for LoadUS; it could be renamed to LoadUS).

If we rewrite LoadB/AndI pairs early to LoadUB, in Node::Ideal(), the  
optimization will be "in the bank" and later transformations cannot  
interfere with it.

-- John

On Jan 15, 2009, at 10:51 AM, Vladimir Kozlov wrote:

> I looked on your previous post.
>
> Again there is no enough information.
> Is this graph produced after you changed something in C2?
> 311 is the loop's entry control so LoadB is placed
> outside the loop but AndI and StoreC is inside the loop.
> This makes no sense for this case.
>
> Christian, I would suggest to look on this loop before first
> unrolling/peeling.
> You may use visualizer to see how the graph evolves.



More information about the hotspot-compiler-dev mailing list