Peter Bergner wrote:
On Thu, 2008-05-08 at 11:38 -0700, Steve Ellcey wrote:
The psuedo for %r8 does have REG_POINTER set and the psuedo for %r19
does not. I first see REG_POINTER set for ivtmp___1536 (the psuedo for
%r8) in flow.c.138r.loop2_invariant. This seems interesting because
Peter's patch, that fixes this problem without undoing Andrews patch,
includes a change to loop-invariant.c, though that change should be
preserving REG_POINTER's during optimization not preventing them.
Similar to hppa, power6 cares about knowing whether a pseudo is a pointer
OK. Reasonably simpler, though on the PA if you get it wrong, you get a
hard failure rather than just poor performance :(
What I found, was that the loop invariant and
GCSE code were creating some pseudos to copy expressions into, but was
failing to copy the REG_POINTER/MEM_POINTER attribute along with it.
I recall. I was briefly worried that GCSE might have a problem similar
to the tail merging problem I mentioend briefly, but I just did a quick
audit and it looks clean (basically it doesn't take commutativity into
account when hashing values).
I can't offhand think of how LICM would run afoul muck things up in the
way we're seeing, but obviously something isn't working the way we
expect it to :-)
jeff
