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