This is the mail archive of the gcc-patches@gcc.gnu.org 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]
Other format: [Raw text]

Re: gcc-64 on HP-UX 11.00


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


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