public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: [Linux-ia64] Re: optimization/3783
@ 2001-09-06 15:16 Jim Wilson
  0 siblings, 0 replies; only message in thread
From: Jim Wilson @ 2001-09-06 15:16 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR optimization/3783; it has been noted by GNATS.

From: Jim Wilson <wilson@cygnus.com>
To: jessica@cup.hp.com
Cc: wilson@redhat.com, gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org,
        linux-ia64@linuxia64.org, davidm@hpl.hp.com, gcc-bugs@gcc.gnu.org,
        nobody@gcc.gnu.org
Subject: Re: [Linux-ia64] Re: optimization/3783 
Date: Thu, 06 Sep 2001 14:57:35 -0700

 You have identified the right piece of code to look at, but the suggested
 fix is not right.
 
 POST_MODIFY is an addressing mode.  It is valid only as part of a MEM, it
 isn't valid as a SET_SRC.  What your patch does by accident is disable the
 recursion in canon_rtx because it recurs on PLUS, but not on POST_MODIFY.
 
 The real problem here is that we have some shared RTL being destructively
 modified.
 
 We have two instructions:
 	...*fp...
 	reg350 = fp + 1
 
 When the alias analysis code sees the second instruction, it determines
 that the SET_SRC does not vary (!rtx_varies), and stores it in reg_known_value.
 Later, the AUTO_INC_DEC code modifies the sequence to this
 	reg350 = fp
 	...*reg350...
 	reg350 = reg350 + 1
 We do this so that we can now combine the two insns to use a POST_MODIFY
 addressing mode.  We change the assignment by destructively modifying it in
 place.  We when do this, we accidentally also change reg_known_value which
 is shared RTL.  We now have
 	reg_known_value[350] = r350 + 1
 which is nonsense, because reg_known_value is supposed to be a function
 invariant value.  This causes canon_rtx to go into the infinite loop.
 
 We could fix this by unsharing RTL, but I think there is a deeper problem
 here.  When flow modifies the instruction sequence, it is invalidating
 the alias info.  reg350 is no longer set only once, and hence it is wrong
 to have any reg_known_values value for it.  Thus I think the right fix is
 to add an interface to the alias code so that we can invalidate a
 reg_known_values entry.  Then the AUTO_INC_DEC code that does this
 transformation would call into alias.c to invalidate reg_known_values for
 r350.  The aliasing code previously did not need any invalidate support
 because it was originally only used in the scheduler, and the scheduler
 does not do any code transformations like this, it only reorders code.
 
 Jim
 
 	


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2001-09-06 15:16 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-09-06 15:16 [Linux-ia64] Re: optimization/3783 Jim Wilson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).