Quoting Joern Rennecke <amyl...@spamcop.net>:
Quoting Richard Henderson <r...@redhat.com>:
>>> (define_expand "one_cmplsi2"
...
Why not combine these? I'm pretty sure that expand_binop will try the xor
solution all on its own.
Actually, it's expand_unop, and it doesn't. Left to its own devices, it
will generate a libcall instead.
Of course, if gpr_operand were to include -1 when m1reg is available, and
you swapped all the constraints to something other than "r", you get even
this for free.
That makes sense. IIRC I did something similar to that that for on the SH64.
Except it's a lot of trouble to swap out all the constraints (reload still
needs r, so all affected constraint strings become longer), so there was a
separate predicate to be used in the insns where this was profitable.
AFAICT the opportunities for -1 to be useful are likewise there, but
limited -
xor, mul, shift.
OTOH there might be more constants later than can be available in a register.
so I'm thinking of "ggpr_operand" for general gpr operand (well, there's
two general in there, but gpr_or_reg_cst_operand seems too long) which
is gpr_operand or any constant that's available in a fixed register.
Then rRcf (Rcf : non-regclass Register constraint: constant in fixed
register)
can be the associated constraint.
Actually, it's not that simple. The not:SI operaration can be generated
by combine. But it won't generate (xor:SI (reg:SI foo) (const_int -1)) .
So I need one_cmplsi2_i as combiner pattern no matter what.
It makes sense to expand straight to that pattern though, to avoid hoisting -1
out of a loop.
