> 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
