This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Improve i386 add
> On Fri, Mar 28, 2003 at 12:28:27PM +0100, Jan Hubicka wrote:
> > + ;; We do not force operand 1 to match operand 0 because we can use LEA.
> > + ;; Alternative 2 is needed to avoid lea being used when operand 2 match
> > + ;; operand 0 as reload no longer is required to reorder the operands for us.
> > (define_insn "*adddi_1_rex64"
> > ! [(set (match_operand:DI 0 "nonimmediate_operand" "=r,rm,r,r")
> > ! (plus:DI (match_operand:DI 1 "nonimmediate_operand" "%0,0,r,r")
> > ! (match_operand:DI 2 "x86_64_general_operand" "rme,re,0,re")))
>
> I disbelieve you need this. The comment about reload is just false;
> it *never* was required to reorder the operands.
>
> > (match_operand:DI 2 "x86_64_nonmemory_operand" "")))
> > (clobber (reg:CC 17))]
> > "TARGET_64BIT && reload_completed
> > + && true_regnum (operands[0]) != true_regnum (operands[2])
> > && true_regnum (operands[0]) != true_regnum (operands[1])"
> > [(set (match_dup 0)
> > (plus:DI (match_dup 1)
>
> Why isn't this sufficient? Modulo the fact that it would seem
> you're potentially calling true_regnum on a CONST_INT.
Because the add pattern will then use alternative 4, or will recog
match it in the reordered order because of '%'?
It does not seem to be the case - constrain_operands countains:
case '?': case '!': case '*': case '%':
case '=': case '+':
break;
So I believe reload is reordering the operands to match it and '%' is
ignored afterwards. Reload does not reorder because of the 4th
altenrative and thus we need alternative 3.
Honza
>
>
> r~