This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][ARM] Fix broken shift patterns


> Done, and attached.

Ok.

Two changes to the testcase that I'll pre-approve:
- Add a comment along the lines of
  /* ARM has shift-and-alu insns.  Depending on the ALU op GCC represents some
   of these as a left shift, others as a multiply.  Check that we match the
   right one.  */
- Also test (a * 64) - b [rsb] and ~(a * 64) [mvn]

> > 3. Consistently accept both power-of-two and 0..31 for shifts.  Large
> > shift counts give undefined results[1], so replace them with an
> > arbitrary value (e.g. 0) during assembly output.  Argualy not an
> > entirely "proper" fix, but I think it'll keep everything happy.
> 
> I think we need to be careful not to change the behaviour between
> different optimization levels and/or perturbations caused by minor code
> changes. I know this isn't a hard requirement for undefined behaviour,
> but I think it's still good practice.

> In this case, I believe the hardware simply shifts the the value clean
> out of the register, and always returns a zero (or maybe -1 for
> ashiftrt?).

I'm not convinced.  ARM instructions shift modulo 256
(i.e. a >> (b & 0xff).  I'm pretty sure anything that gets constant-folded by 
earlier passes will not honor these semantics.
 
> > For bonus points we should probably disallow MULT in the arm_shiftsi3
> > pattern, stop it interacting with the regular mulsi3 pattern in
> > undesirable ways.
> 
> How might that be a problem? Is it not the case that canonical forms
> already deals with this?

Mainly just general principle that having two insns with the same pattern is 
wrong - reload can't flip between them like it can different altrnatives, and 
there's obscure rules about which one wins when both match.

In this case the shiftsi variant is very restricted and should never occur in 
the first place so it probably doesn't matter.

Paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]