Bad code generation on HPPA platform

[Jeff Law]

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