Re: g++ pointer tracking question

[Steve Ellcey <sje@cup.hp.com>]

> Passing an offset is right.  REG_POINTER should not be true, but I wouldn't
> expect it to break anything.  The problem is that the C++ frontend uses
> POINTER_TYPE to describe pointer-to-member types; this is conceptually
> wrong, but nobody has gotten around to fixing it yet.
> 
> I think your bug lies elsewhere.

No, I think this is it.  While this works OK in 64 bit mode and may not
cause problems for other platforms, in 32 bit mode (HP-UX IA64) we
really need to know if something is a pointer or not for one of our
(platform specific) optimizations.

Details for the curious:

IA64 extends 32 pointers to 64 bits using an instruction known as
"addp4", which can take two arguments, a 32 bit pointer and an offset
(constant integer or another register), and it gives you a result by
adding the two together and then copying bits 30 and 31 of the pointer
argument to bits 61 and 62.  The bits copied are only from the register
that is supposed to contain a pointer, not the register that contains an
offset.

If you do it in two steps; add the two numbers, then addp4 the result it
doesn't matter which value is an address and which is an offset.  You
just add them together and then do an addp4 with a constant offset of 0.
If you want to combine the two steps into a single instruction it
matters very much that the register you think has a pointer in it really
does.

So my problem is I have two 32 bit numbers, both show up as pointers and
I just happen to luck out and pick the wrong one when I try to use one
as the pointer register in my addp4 instruction.

Maybe I can modify ia64.md to say that the addp4_plus_[12] instructions
that combine an add and an addp4 into one instruction cannot be used if
both arguments show up as pointers.  I don't think I am up to fixing the
C++ front-end.

Steve Ellcey
sje@cup.hp.com