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