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]

Re: [Patch] 1/2 Expand sync_sub as sync_add if predicates don't match.


David Daney <ddaney@avtrex.com> writes:
> While implementing the atomic memory operations for MIPS, I came across 
> a problem where immediate operands were forced into a register when 
> sync_sub* insns were expanded.  On MIPS there is no minus instruction 
> for immediate operands, instead this should be expanded as plus with the 
> negative value of the immediate operand.
>
> In expand_sync_operation() and expand_sync_fetch_operation() there is 
> code to handle conversion to plus if the minus insn does not exits.  I 
> enhanced this slightly so that it also does the conversion if the 
> predicate for sync_sub* does not match, but it does match for the 
> corresponding sync_add*.  This allows me to write sync_sub* insns with a 
> register predicate and have them used for non-immediate operands, but an 
> immediate operand results in conversion to sync_add*.
>
> Tested on x86_64-pc-linux-gnu all default languages both native and -m32 
> with no regressions.  Also tested mips64-linux C only.
>
> :ADDPATCH middle-end:
>
> OK to commit?

FWIW, with (minus ... (const_int ...)) not being canonical rtl, I think
we should always use PLUS rather than MINUS if the operand is a CONST_INT.
E.g. the first thing expand_binop does is:

  /* If subtracting an integer constant, convert this into an addition of
     the negated constant.  */
  if (binoptab == sub_optab && GET_CODE (op1) == CONST_INT)
    {
      op1 = negate_rtx (mode, op1);
      binoptab = add_optab;
    }

and I think we should have a similar thing in expand_sync_operation
and expand_sync_fetch_operation.  As well as avoiding invalid
expressions, it has the advantage of folding the negation at
generation time, which I don't think the current version would.
(Sorry if that's wrong.)

Richard


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