On 04/03/2019 09:04, Jakub Jelinek wrote: > On Fri, Mar 01, 2019 at 03:41:33PM +0000, Wilco Dijkstra wrote: >> > and regtest revealed two code size >> > regressions because of that. Is -1 vs. 1 the only case of immediate >> > valid for both "I" and "L" constraints where the former is longer than the >> > latter? >> >> Yes -1 is the only case which can result in larger code on Thumb-2, so -1 >> should >> be disallowed by the I constraint (or even better, the underlying query). >> That way >> it will work correctly for all add/sub patterns, not just this one. > > So, over the weekend I've bootstrapped/regtested on armv7hl-linux-gnueabi > following two possible follow-ups which handle the -1 and 1 cases right > (prefer the instruction with #1 for thumb2), 0 and INT_MIN (use subs) and > for others use subs if both constraints match, otherwise adds. > > The first one uses constraints and no C code in the output, I believe it is > actually more expensive for compile time, because if one just reads what > constrain_operands needs to do for another constraint, it is quite a lot. > I've tried to at least not introduce new constraints for this, there is no > constraint for number 1 (or for number -1). > The Pu constraint is thumb2 only for numbers 1..8, and the alternative uses > I constraint for the negation of it, i.e. -8..-1, only -1 from this is > valid for I. If that matches, we emit adds with #1, otherwise just prefer > subs over adds. > > The other swaps the alternatives similarly to the above, but for the special > case of desirable adds with #1 uses C code instead of another alternative. > > Ok for trunk (which one)? > > Jakub
Option #2 is better (the C code variant)- for something like this adding one more constraint is a bit painful. Ok and watch out for any regressions as usual. Ramana
