This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: gcc-64 on HP-UX 11.00
- From: law at redhat dot com
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: h dot m dot brand at hccnet dot nl, gcc-patches at gcc dot gnu dot org
- Date: Wed, 01 May 2002 15:12:40 -0600
- Subject: Re: gcc-64 on HP-UX 11.00
- Reply-to: law at redhat dot com
In message <200205012052.g41Kqdiu017187@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
> > Once we preferred GENERAL_OR_FP_REGS the allocator is free to select any
> > register
> > from that class, including an fp register. Preferring GENERAL_OR_FP_REGS
> > indicates that either a GPR or FPR will work fine with equal cost.
>
> Given equal costs, shouldn't the first matching alternative have been
> selected?
Nope. Given equal costs, you want to expand the set of possible allocations
to give the allocator the most freedom.
> Possibly, the problem is that we allocate the FPRs first.
Given equal costs (as was the case with the "T" constraint bug), we'll
fall back on REG_ALLOC_ORDER which will tend to prefer FP regs. That
was done years ago as it was generally found to improve real world
integer code (more sane allocations in the presence of xmpyu).
> With the patch as it stands, it's still appears possible to load
> a DI mode value into a FPR. Shouldn't we disparage this because
> we really normally want a GPR?
It's certainly possible to load DI values into FPRs. It's very very
important that we still have that ability. Again, remember xmpyu.
What is important here is whether or not an address load will ever end
up in an FPR. While I believe it may be possible in theory, I don't
believe it will be possible in practice, except due to bugs elsewhere
in the compiler (such as the "T" constraint bug).
For it to be possible, you'd have to end up with a pseudo which preferred
FP_REGS (or one of the superclasses). That's extremely unlikely to happen
as an address load will always locally prefer a GPR as that's the only
target register which can directly satisfy the constraints of such insns.
I think to get the case you're worried about you'd have to do something
extremely weird, like use the pseudo in two different contexts. In one
context you'd want to do a bunch of multiplies on it (to generate xmpyu
insns and cause the pseudo to prefer FP regs). In the other context
you'd want to use it as a pointer to an object in static storage.
jeff