[aarch64-port-dev ] RFR: 8151661: Performance regression on Solaris-SPARC in 9-b103

[Rahul Raghavan]

Hi,

Request help suggestions here.
With reference to RFR email thread, to go forward can the following be done? -

- Close 8151661 with <webrev.00> changes  http://cr.openjdk.java.net/~rraghavan/8151661/webrev.00/
- Open new separate, related bug for required AArch64 changes.
- If required create a sub-task for the new bug, to quarantine 'hotspot/test/compiler/codegen/8144028/BitTests.java'.

Thank you,
Rahul

> -----Original Message-----
> From: Andrew Dinn [mailto:adinn at redhat.com]
> Sent: Thursday, June 09, 2016 1:30 PM
> To: Andrew Haley; aarch64-port-dev at openjdk.java.net
> Subject: Re: [aarch64-port-dev ] RFR: 8151661: Performance regression on Solaris-SPARC in 9-b103
> 
> On 08/06/16 17:51, Andrew Haley wrote:
> > OK, I'll go for that.  So, rather than what I have now:
> >
> > instruct cmpL_branch_bit(cmpOp cmp, iRegL op1, immL op2, immL0 op3, label labl) %{
> >   match(If cmp (CmpL (AndL op1 op2) op3));
> >   predicate((n->in(1)->as_Bool()->_test._test == BoolTest::ne
> >             || n->in(1)->as_Bool()->_test._test == BoolTest::eq)
> >             && is_power_of_2(n->in(2)->in(1)->in(2)->get_long()));
> >
> > I'd have to find some way to express the predicate as a pattern.
> >
> > I know how to do the is_power_of_2 part as an operand in the pattern.
> > I'm not sure how to express the idea that this must only match an EQ
> > or NE cmpOp without using a predicate to distinguish.
> 
> I'm not certain this will work but you might try the following:
> 
> cmpOp is defined by an operand definition matching Bool (the defn is in
> aarch64.ad). It includes an INTERFACE declaration which allows it to
> operate as a compare operator with the right condition codes.
> 
> If you introduce a similar operand cmpOpEqNe you can add a predicate in
> that operand which includes the same checks on _test as the predicate
> for the rule above (except you use n rather than n->in(1)->as_Bool()). I
> think you should then be able to use that operand to type the rule input
> and the matcher will pre-enforce the constraint before matching using
> the new rule.
> 
> You might have to introduce an operand cost preferring cmpOpEqNE over
> and cmpOp to make this work (although actually I think it may well just
> work without).
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander