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]

P.S.: Re: RFA: Add Epiphany port


Quoting Joern Rennecke <amylaar@spamcop.net>:

Quoting Richard Henderson <rth@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.


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