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: Fix powerpc-linux gcc.dg/20020103-1.c



On 29/11/2004, at 11:37 AM, Geoff Keating wrote:



On 25/11/2004, at 9:32 PM, Alan Modra wrote:


On Wed, Nov 10, 2004 at 12:58:25PM +1030, Alan Modra wrote:
On Mon, Nov 08, 2004 at 10:01:33PM +1030, Alan Modra wrote:
This fixes 20020103-1.c with a minimal change.

The same for gcc-3.4.

Ping! http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00583.html and http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00789.html

In my previous mail, I said:


I don't think this patch is the right direction.  You're working
around reload in the backend.  Instead, you should teach reload how to
load from a SYMBOL_REF.  I believe this is just a change to
rs6000_emit_move.

Why didn't you do that?

Oh, I see, you said:


> I don't think this patch is the right direction.  You're working
> around reload in the backend.

Not really.  I'm delaying generation of unspec rtl that generic code
can't handle.  Surely that is a good thing, as it fits in with the
philosophy of keeping target dependent wrinkles out of intermediate
representations as long as possible.  As demonstrated by the fact that
this change allows us to generate ideal code without further
complicating reload with target dependent information.

No, there's a right time to introduce target dependencies, and the right time for a load operation is before sched1.


Of course, that argument fails if you really need the unspec early.
I'm reasonably confident we don't.  As far as I can tell,
unspec_movsi_got was a half-baked attempt to reserve r30 early
enough so that r30 was free to use if a function didn't make any got
accesses.  True?

Yes; but why can't we do that?


>  Instead, you should teach reload how to
> load from a SYMBOL_REF.  I believe this is just a change to
> rs6000_emit_move.

I looked at changing reload before taking the approach I did.  It's not
quite as simple as you indicate, ie. more than just rs6000_emit_move
needs changing, I think.

Can you go into more details?


Note that the patch you presented in the URLs above doesn't delay generation of anything, and in fact goes exactly against the direction you said was a good thing.

Attachment: smime.p7s
Description: S/MIME cryptographic signature


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