Painful problems with -fpic implementation on powerpc-sysv

Geoff Keating geoffk@ozemail.com.au
Fri Aug 21 12:51:00 GMT 1998


> Cc: egcs@cygnus.com, Franz Sirl <Franz.Sirl-kernel@lauterbach.com>,
>         Jeffrey Law <law@cygnus.com>
> Date: Thu, 20 Aug 1998 14:04:57 -0400
> From: David Edelsohn <dje@watson.ibm.com>

> 	FP constants can be materialized in GPRs and transferred to FPRs.
> The define_splits for loading CONST_DOUBLEs into FPRs specifically test
> reload_completed.  The problem seems to be the use of a memory location
> that requires the GOT instead of the stack.

Yes.  My patch (attached to that e-mail message) `fixes' the problem
in a really ugly way by forcing egcs to use the stack, not the GOT.

> 	Does GCC decide early on that it will construct the constant in
> the GOT pool and load from there but then doesn't have the GOT
> handy? 

No, that's why the problem is so rare.  GCC can only see that it is
going to use the constant pool once it has allocated registers; before
then, it looks like it would load the constants into a general
register which it can do with immediate operands.

> In these cases is there some way to convince GCC to reload the value
> directly via an alternative method instead of from the GOT slot?

That is what my patch does: it forces reload to try some other
alternative.  My patch has to add an extra hook to force this; H.J
suggested `CONST_DOUBLE_OK_FOR_LETTER_P' but that seems to be
something else (the name is good, but it isn't called when the letter
is 'm' or 'o' :-).  I don't dare to change the meaning of something
like that because it would surely break other ports.

I have now built glibc and tcl 8.0.2 with my patch (with that abort()
commented out), and current glibc, and nothing seems to have gone
wrong.  However, I have spotted one bug; it should be

#define AVOID_RELOAD_CONST_MEM(X) (flag_pic == 1 && too_late_for_got)

although this doesn't affect correctness, just code quality.

In fact, I think you could possibly eliminate all the too_late_for_got
changes altogether, the macro is only used in places when it's too
late.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>



More information about the Gcc mailing list