This is the mail archive of the 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 40/50] rtlanal.c:for_each_inc_dec

On 08/26/14 13:28, Richard Sandiford wrote:
[Jeff, sorry for the duplicate, sent the original from an account that
adds disclaimers.]
No worries. Given the 3000+ messages that were waiting for me when I got back from PTO, what's another duplicate here and there :-)

[ Big snip. ]

invalid and cope with it if we ever find one.  Perhaps a bit of
ENABLE_CHECKING to detect if we ever create such a note?

I suppose an assert means that it'd be up to each piece of code that
creates a note to check whether the equivalent value has autoinc addresses.
How about just dropping those REG_EQUAL and REG_EQUIV notes instead,
like we already do for ASM_OPERANDS?
I can live with that.

Here I've extended it to all notes with side effects.  The additional
cases are:

     case CLOBBER:
       /* Reject CLOBBER with a non-VOID mode.  These are made by combine.c
	 when some combination can't be done.  If we see one, don't think
	 that we can simplify the expression.  */
       return (GET_MODE (x) != VOIDmode);

     [...snip autoincs...]
     case CALL:
       return 1;

     case MEM:
     case ASM_INPUT:
     case ASM_OPERANDS:
       if (MEM_VOLATILE_P (x))
	return 1;

The combine clobbers shouldn't make their way into a note anyway,
since it represents a failed optimisation.  ASM_INPUT is a top-level
rtx rather than a SET_SRC, so isn't important.  Checking for volatile
ASM_OPERANDS is just a subset of the current:

       /* Don't add ASM_OPERAND REG_EQUAL/REG_EQUIV notes.
	 It serves no useful purpose and breaks eliminate_regs.  */
       if (GET_CODE (datum) == ASM_OPERANDS)
	return NULL_RTX;

So the remaining cases are CALL, UNSPEC_VOLATILE and volatile MEMs.
I think UNSPEC_VOLATILE and volatile MEMs really do fall into the same
category as auto-inc/dec.

 Const CALLs should be OK in practice,
but I'm not sure why they'd ever need to be treated as having
side effects.
They probably don't, but I think that's independent of your changes. There may be subtle things that depend on the const calls having "side effects" -- for example, they might be considered as clobbering argument saveback aeras on the stack and other such nonsense.

  Other CALLs are more dangerous.  In practice the only
interesting notes for calls are (a) that the call address is equal
to some other rtx, which is recorded in the insn that sets the
address register rather than on the call itself and (b) that the result
of the call is equivalent to some non-CALL rtx (e.g. after a libcall).
Clearly dropping these is safe as well. And in the case of a libcall, the note shouldn't look like a call, the note should be the "obvious" RTL form that the libcall is implementing. ie instead of a call to mulsi the note looks like (mult (a) (b))

Tested on x86_64-linux-gnu.  OK to install?


	* emit-rtl.c (set_unique_reg_note): Discard notes with side effects.


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