This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: A patch for -fpic and -fomit-frame-pointer on x86
- To: hjl at lucon dot org (H.J. Lu)
- Subject: Re: A patch for -fpic and -fomit-frame-pointer on x86
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 14 Jul 1998 01:02:57 -0600
- cc: egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
In message <m0yvxl2-000266C@ocean.lucon.org>you write:
> I don't think so. It can only happen to fp constants on Intel. The
> whole mess is caused by that only 2 or 3 fp constants are allowed
> as the immediate operands.
But my point is lots of other instructions allow immediate operands, are
there cases where due to the actions of reload where one of those
immediate operands could get forced into memory?
If not, please explain in more detail why. I'm not looking for yes
or no, but some explanation of why it can not happen for integer
operands. I don't want to have to tackle this problem again in
6 months because we find out it does happen for integer operands too.
As for the patch itself, I don't think it is correct to be testing
reload_completed or reload_in_progress within the CONST_... macros.
Nor do I see how checking reload_completed is useful. Can you please
explain why you think you want/need that check?
Seems to me that you should just check !flag_pic.
jeff