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: Deep CSE bug!

On Fri, 18 Jun 2004, Dave Korn wrote:
>   Does really nobody have anything to say about the semantics of REQ_EQUAL
> on SETs of SUBREGs?  The internals menu talks about the case where you have
> a STRICT_LOW_PART of a SUBREG but doesn't say anything about the plain
> SUBREG case.  I would have thought the mode of the expression in the note
> ought to be the same as the mode of the SUBREG rather than the inner REG,
> perhaps?

My understanding (and working hypothesis) of REG_EQUAL notes is that they
describe the SET_SRC of a SET instruction, and their interpretation is
completely independent of the set's target, SET_DEST.

I believe the semantics are (or should be) that given an instruction

	(set (foo) (bar))
	  (REG_EQUAL  baz)

that it is the REG_EQUAL note states that at the point this instruction
is executed "bar" will have the same value as "baz".  The REG_EQUAL note
is used to record the equivalence when (set (foo) (baz)) is either not
not recognized/available as a backend, or has a higher cost than the
original.  In normal use, "baz" will be more grounded (contain more
constants) than "bar".  In the RTL optimizers, it should always be
valid to reasonable the SET_SRC on an instruction with its REG_EQUAL
note (except when the REG_EQUAL notes contains an expression list).

This also clarifies the expected behaviour when "baz" references "foo".
The contains of the REQ_EQUAL note are not available after the
assignment if any component is clobbered by its SET.

In your and Kaz's examples, it sounds like the bug is that the
REG_EQUAL note is invalid/incorrect, rather than a flaw in CSE.

Perhaps someone else could comment on, confirm or deny these semantics?


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