Request for review (L): 6797305: Add LoadUB and LoadUI opcode class

Tom Rodriguez Thomas.Rodriguez at Sun.COM
Fri Mar 6 10:29:07 PST 2009


I'm very confused by your explanation of what's going wrong.   
Originally you said:

mm, JPRT failed and it seems there is a matcher problem.  It matches:

  match(Set dst (ConvI2L (LoadUB mem)));

instead of:

  match(Set dst (ConvI2L src));

But there is no LoadUB node around.  Are there any matcher restrictions
that I don't know about?

But below you say that if you remove that instruction it matches the  
ConvI2L LoadUB pattern so which one did it do?  Also what is "that  
instruction"?  What kind of node is src if it's not a LoadUB?

I really can't see the matcher matching the wrong node unless there  
are some problems with your adlc changes.  Node matching is all driven  
by the Opcode().

tom

On Mar 6, 2009, at 9:46 AM, Christian Thalinger wrote:

> On Fri, 2009-03-06 at 09:38 -0800, Vladimir Kozlov wrote:
>> Is this
>>
>> Is it possible that matcher is confused by the cost?
>> You changed the cost of ConvI2L:
>>
>>   instruct convI2L_reg( eRegL dst, eRegI src, eFlagsReg cr) %{
>>     match(Set dst (ConvI2L src));
>>     effect(KILL cr);
>> +   ins_cost(375);
>>
>> and cost of "ConvI2L (LoadUB" is lower:
>>
>> ! instruct loadUB2L(eRegL dst, memory mem)
>> ! %{
>> !   match(Set dst (ConvI2L (LoadUB mem)));
>> !
>> !   ins_cost(250);
>
> Ahh, sorry, I didn't mention that this happens on x86_64.  I just  
> wonder
> why the matcher matches the rule when there is no LoadB that could be
> matched.  If I remove that instruction, then the next is matched:
>
>  match(Set dst (ConvI2L (LoadUB mem)));
>
> -- Christian
>




More information about the hotspot-compiler-dev mailing list