A patch for -fpic and -fomit-frame-pointer on x86

H.J. Lu hjl@lucon.org
Mon Jul 13 13:26:00 GMT 1998


> 
> 
>   In message < m0ytuCX-000266C@ocean.lucon.org >you write:
>   > > If so, the bug is clearly in INITIAL_ELIMINATION_OFFSET.  
>   > > 
>   > 
>   > Well, it is hard for the first INITIAL_ELIMINATION_OFFSET to tell if
>   > PIC will be ever used. It depends on values of FP constants, CPU and
>   > optimization.
> As I mentioned in an earlier message, depending on those things is
> not safe.
> 
> Make it always include space for the PIC register on the stack and
> make the prologue always reserve the space.
> 

I took a look at your suggestion. It may have a major impact on
shared library on x86. It means every function in shared library
has to save/restore the PIC register even if the PIC register is
not used at all. On Intel, push/pop may be faster than sub/add.
That means we cannot optimize the function return in shared library
since ix86_can_use_return_insn_p may have to always return 0 for PIC.

I think the following patch may be more appropriate given what we
can do. Basically it says it is not safe to assume we can have fp
constatnt as operand with PIC.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)
----
Sun Jul 12 21:08:23 1998  H.J. Lu  (hjl@gnu.org)

	* config/i386/i386.c (standard_80387_constant_p): Return 0
	for PIC.

Index: config/i386/i386.c
===================================================================
RCS file: /home/work/cvs/gnu/egcs/gcc/config/i386/i386.c,v
retrieving revision 1.1.1.25
diff -u -p -r1.1.1.25 i386.c
--- i386.c	1998/07/07 15:09:58	1.1.1.25
+++ i386.c	1998/07/13 18:05:46
@@ -1556,6 +1556,9 @@ standard_80387_constant_p (x)
   jmp_buf handler;
   int is0, is1;
 
+  if (flag_pic)
+    return 0;
+
   if (setjmp (handler))
     return 0;
 



More information about the Gcc-bugs mailing list