On Wed, Jul 03, 2019 at 05:26:58PM -0500, Segher Boessenkool wrote:
> On Thu, Jul 04, 2019 at 06:49:17AM +0900, Stafford Horne wrote:
> > On Wed, Jul 03, 2019 at 09:49:02AM -0500, Segher Boessenkool wrote:
> > > On Wed, Jul 03, 2019 at 12:33:49PM +0900, Stafford Horne wrote:
> > > > @@ -179,11 +183,11 @@
> > > > [(set (match_operand:SI 0 "register_operand" "=r,r")
> > > > (rotatert:SI (match_operand:SI 1 "register_operand" "r,r")
> > > > (match_operand:SI 2 "reg_or_u6_operand" "r,n")))]
> > > > - "TARGET_ROR"
> > > > + "TARGET_ROR || TARGET_RORI"
> > > > "@
> > > > l.ror\t%0, %1, %2
> > > > l.rori\t%0, %1, %2"
> > > > - [(set_attr "insn_support" "*,shftimm")])
> > > > + [(set_attr "insn_support" "ror,rori")])
> > >
> > > Does this work? If you use -mno-ror -mrori? It will then allow
> > > generating
> > > a reg for the second operand, and ICE later on, as far as I can see?
> >
> > It does seem to work. Why would it produce an internal compiler error?
> >
> > One thing I have is RegectNegative on mror and mrori, so -mno-ror will not
> > be
> > allowed and cause an error.
>
> But both options are off by default, and neither is enabled or disabled
> based on the setting of the other.
>
> > Example:
> >
> > $ cat ./gcc/testsuite/gcc.target/or1k/ror-4.c
> >
> > unsigned int rotate6 (unsigned int a) {
> > return ( a >> 6 ) | ( a << ( 32 - 6 ) );
> > }
>
> That's a fixed distance rotate. My question is will it work if the
> distance is a variable. The other direction should work fine, agreed.
>
> So, does ror-[12].c work with -mrori and no -mror? The predicates say
> this insn pattern is just fine in that case, but the constraints will
> disagree.
OK, yes I see it now. Sorry I mis-understood what you meant by second argument.
I will fix. It's probably going to be easiest to split this to 2 instructions.
-Stafford
