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]


  In message <>you write:
  > Here's a patch that improves execution time by a factor of three, for
  > one loop I've been looking at.  It reduces instruction count by a
  > similar factor, partly by enabling other optimizations.
  > When we had something like:
  >   (SET (REG 1) (ADDRESSOF (REG 2)))
  >   (SET (MEM (REG 1)) (REG 3))
  > CSE's find_best_addr decided that REG1 was a great address because it
  > was already in a register, and (ADDRESSOF (REG 2))) was lousy because
  > it had a higer ADDRESS_COST.  This patch introduces a new macro, for
  > use only in CSE because after that point ADDRESSOFs are purged, which
  > favors (ADDRESSOF (REG)).  That allows other mechanisms in CSE to
  > simplify (MEM (ADDRESSOF (REG 2))) to just plain REG 2.
I'm not sure if this is safe.  Consider if the ADDRESSOF was used
because we needed to take the address of a local variable and pass
it to a subroutine.  Then assume the subroutine stores into the the

Later we have a read of that variable via (mem (adddressof (reg)) that
we turn into (reg) and miss the side effect of the subroutine call we
just made.  In fact, we've already got a bug of this nature that was
reported yesterday :(

Seems to me this is only safe if we can eliminate every addressof for
a particular register.

I think we can create (mem (addressof (reg)) expressions in cse, but
we can't collapse it into (reg) until we purge the addressof expressions..


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