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

[John Rose]

Yes.  It's a valid ideal node type, not hardware specific and useful  
to optimizations.

IMO, matcher-based optimizations are nice-to-haves, not  
requirements.  If you have a optimization you really need, make it in  
the ideal graph.  This is such a case.

(As an aside, I would like to see someone dig into the matcher, and  
record the (re-)learning process on http://wikis.sun.com/display/ 
HotSpotInternals .)

-- John

On Jan 16, 2009, at 6:29 AM, Christian Thalinger wrote:

> On Thu, 2009-01-15 at 12:51 -0800, John Rose wrote:
>> 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.
>
> Should I try to make that changes?
>
> -- Christian
>