From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bill Currie To: law@cygnus.com Cc: Joern Rennecke , ak@muc.de, egcs@cygnus.com Subject: Re: Feature request: ability to describe x86 register halves as contraints. Date: Thu, 02 Jul 1998 01:39:00 -0000 Message-id: <359AFFE1.26F8@tssc.co.nz> References: <23540.899348404@hurl.cygnus.com> X-SW-Source: 1998-07/msg00079.html Jeffrey A Law wrote: > > Sometimes I think the amount of effort required is grossly > > over-estimated (but not allways). > I disagree. One of the things I do for Cygnus is estimations and > estimation review -- my opinions based on that would tend to be just > the opposite. While many problems seem easy on the surface, when you > dig deeper you often find fundamental problems that throw off estimations > by 2X-5X. Sorry. However, I found that I didn't have to change gcc's assumptions about register/memory ordering to get my port to work. > And whie this may be working for you, I highly suspect if you dig deeper > you'll find out that all kinds of things eventually break. My initial attempts did exactly that. I did the silly thing of trying to cross the registers over when going from fp<->int register. everything blew up very badly. However, I get a successfull stage3 build and compare. Does that count? > The i860 port is probably buggy as hell. Nobody's working on it at all. In that case, should I submit my patches anyway so at least they won't get lost? Also, I would like feedback on what I've done from knowledgable people. > I would think this will work as long as you have appropriate matchers. There are already matchers, so I'll just give it a go and see what happens. > However, I'm curious how you deal with memory subregs or register > subregs that get spilled, then loaded from memory. Hmm... now, I could have missed something, but the existing i860 md file has relatively few references to subregs. The only time I had any real problems was getting MULSI3 to work cleanly. This required hacking in use of strict_low_part, probably to get around this very issue. I might even find a cleaner solution. Also, I could be very wrong (especially because I'm not too sure what spilling is), but how often do subregs get spilled? Hmm, just realised you may be referring to when reload.c strips the subreg info if the subreg is 0. I told push_reload (? bloody big functions) not to strip the subreg info if REG_WORDS_BIG_ENDIAN != WORDS_BIG_ENDIAN. > I get the > impression that how the word of a subreg is interpreted changes based > on what the inner object is. Do you mean whether it's a REG or a MEM object? Yes, that's exactly what I do in final.c as it is selecting the register name. Here's the my patch to final.c that implements this. (there may still be problems with non DI/DF instances, but I haven't encountered any yet). diff -urN rgcs-1.0.3a/gcc/final.c egcs-ftx/gcc/final.c --- foobar/final.c Sun Oct 19 04:22:17 1997 +++ egcs-ftx/gcc/final.c Wed Jun 24 16:05:32 1998 @@ -69,6 +69,10 @@ #include "output.h" #include "except.h" +#ifndef REG_WORDS_BIG_ENDIAN +#define REG_WORDS_BIG_ENDIAN WORDS_BIG_ENDIAN +#endif + /* Get N_SLINE and N_SOL from stab.h if we can expect the file to exist. */ #if defined (DBX_DEBUGGING_INFO) || defined (XCOFF_DEBUGGING_INFO) #if defined (USG) || defined (NO_STAB_H) @@ -2305,8 +2309,19 @@ if (GET_CODE (y) == REG) { /* If the containing reg really gets a hard reg, so do we. */ - PUT_CODE (x, REG); - REGNO (x) = REGNO (y) + SUBREG_WORD (x); + if ((REG_WORDS_BIG_ENDIAN != WORDS_BIG_ENDIAN) && + (GET_MODE (x) != DImode) && + (GET_MODE (x) != DFmode) && + (GET_MODE (y) == DImode || GET_MODE (y) == DFmode)) + { + PUT_CODE (x, REG); + REGNO (x) = REGNO (y) + 1 - SUBREG_WORD (x); + } + else + { + PUT_CODE (x, REG); + REGNO (x) = REGNO (y) + SUBREG_WORD (x); + } } else if (GET_CODE (y) == MEM) { -- Leave others their otherness