sparc64 changes and generic backend patches

sparc64 changes and generic backend patches

[Richard Henderson]

This weekend I merged the sparc64 work to support Sun's official,
though still unpublished, Sparc v9 ABI.  

I went ahead and committed the bits under the sparc subdirectory.
This shouldn't affect sunos, solaris, or sparc-linux users.  It
will affect sparc64-linux users, but then yall have been waiting
on this for some time.

However, as-is it is fairly brittle, as there are generic backend
changes yet to be applied.  I present several of them here.

(1) Attachment 1 rewrites emit_group_load/store to handle all of the
    nifty structure size and alignment problems that do not affect the
    IRIX6 n64 ABI.  The canonical problem struct is

	struct foo { char x[7]; };

    which might live at page_boundary-7.  The old code would produce
    either an unaligned trap or a segmentation fault trying to load
    these bits into the single outgoing 64-bit register.

(2) Attachment 2 disables a check in reload not applicable to Sparc's
    32-bit FP regs when considered with a 64-bit word size.

(3) Attachment 3 contains a few unidentified fixes I found in my tree.
    Most of it consists of propogating a change made by Jeff

    Wed Dec 31 01:28:37 1997  Jeff Law  <law@cygnus.com>

	* expr.c (expand_expr): For {BITFIELD,COMPONENT,ARRAY}_REF, if the
	offset's mode is not ptr_mode, convert it.

    to the other similar cases in the same function.

    It also contains a change to store_expr that appears to be a typo.
    I can't remember the problem it caused, but I present it for your
    consideration.

In addition to this, there appear to be some reload problems that
were not present some months ago.  And some bad interactions with
SImode data in FP regs and the fact that user variables are subject
to promote_mode in stmt.c.  These are not addressed here.


r~

Re: sparc64 changes and generic backend patches

[Joern Rennecke]

> Sun May  3 14:31:16 1998  Richard Henderson  <rth@cygnus.com>
> 
>         * reload.c (find_reloads): Don't prohibit reloading into registers
>         smaller than the word size.
> 
> Index: reload.c
> ===================================================================
> RCS file: /egcs/carton/cvsfiles/egcs/gcc/reload.c,v
> retrieving revision 1.23
> diff -c -p -d -r1.23 reload.c
> *** reload.c    1998/05/01 17:40:50     1.23
> --- reload.c    1998/05/03 21:22:25
> *************** find_reloads (insn, replace, ind_levels,
> *** 2806,2812 ****
>                      registers for subregging to work.  */
>                   || (GET_CODE (operand) == REG
>                       && REGNO (operand) < FIRST_PSEUDO_REGISTER
> !                     && ((GET_MODE_SIZE (operand_mode[i]) <= UNITS_PER_WORD
>                            && (GET_MODE_SIZE (GET_MODE (operand))
>                                > UNITS_PER_WORD)
>                            && ((GET_MODE_SIZE (GET_MODE (operand))
> --- 2806,2815 ----
>                      registers for subregging to work.  */
>                   || (GET_CODE (operand) == REG
>                       && REGNO (operand) < FIRST_PSEUDO_REGISTER
> !                     && ((/* ??? Disable this test because Sparc64 FP regs
> !                             are smaller than one word.  */
> !                          0
> !                          && GET_MODE_SIZE (operand_mode[i]) <= UNITS_PER_WORD
>                            && (GET_MODE_SIZE (GET_MODE (operand))
>                                > UNITS_PER_WORD)
>                            && ((GET_MODE_SIZE (GET_MODE (operand))

If you do that, you have to make sure that subregging works for these
kinds of reloads.
This looks to me like you have to change subregging to count addressable
units instead of words.  That'll be a lot of changes, but sooner or
later we need them anyways, IMO.
You should probably try to coordinate with Richard Kenner to avoid a
split on this issue.

Re: sparc64 changes and generic backend patches

[Jeffrey A Law]

  In message < 19980503145648.58820@dot.cygnus.com >you write:
  > (1) Attachment 1 rewrites emit_group_load/store to handle all of the
  >     nifty structure size and alignment problems that do not affect the
  >     IRIX6 n64 ABI.  The canonical problem struct is
  > 
  > 	struct foo { char x[7]; };
  > 
  >     which might live at page_boundary-7.  The old code would produce
  >     either an unaligned trap or a segmentation fault trying to load
  >     these bits into the single outgoing 64-bit register.
I'd kind of prefer Jim Wilson and David Edelsohn review this and
test it a little.  Jim understands the irix issues and probably
understands the code.  David understands the structure passing
problems for AIX, I don't know if he understands the group load
code.

We've made several attempts to fix these structure passing problems
over the years, many of them we've found out later were incorrect.


  > (2) Attachment 2 disables a check in reload not applicable to Sparc's
  >     32-bit FP regs when considered with a 64-bit word size.
Ouch.  I thought Joern has some concerns about this patch, have you
addressed any of them?


  > (3) Attachment 3 contains a few unidentified fixes I found in my tree.
  >     Most of it consists of propogating a change made by Jeff
  > 
  >     Wed Dec 31 01:28:37 1997  Jeff Law  <law@cygnus.com>
  > 
  > 	* expr.c (expand_expr): For {BITFIELD,COMPONENT,ARRAY}_REF, if the
  > 	offset's mode is not ptr_mode, convert it.
I *vaguely* remember this change.  Wow. I can't remember if I was
trying to solve an Alpha/VMS or some weird mn10200 problem.

These changes look reasonable to me.


jeff

Re: sparc64 changes and generic backend patches

[Richard Henderson]

> > Sun May  3 14:31:16 1998  Richard Henderson               
> >
> >         * reload.c (find_reloads): Don't prohibit reloading into registers
> >         smaller than the word size.                                        
>
> If you do that, you have to make sure that subregging works for these
> kinds of reloads.                                                       

I don't think I understand what you are getting at.  What sort of RTL
are you thinking of?  The case I am trying to solve is as simple as

	(set (reg:SF $f0) (reg:SF 1234))

> This looks to me like you have to change subregging to count addressable
> units instead of words.  That'll be a lot of changes, but sooner or
> later we need them anyways, IMO.

Yes, Jim and I have discussed this problem before.  It will take
a lot of work, but it should be done eventually.  In the mean time
I think I'll have to turn on CLASS_CANNOT_CHANGE_SIZE for the Sparc
FP regs so as to avoid some subregging problems that yet remain.

> You should probably try to coordinate with Richard Kenner to avoid a   
> split on this issue.

I suppose.  Though with the large-scale changes (warning fixes, genrtl)
we already have installed, it would seem we are already approching the
practical limit on sane merging.


r~

Re: sparc64 changes and generic backend patches

[Richard Henderson]

On Fri, May 22, 1998 at 01:16:33AM -0600, Jeffrey A Law wrote:
> I'd kind of prefer Jim Wilson and David Edelsohn review this and
> test it a little.  Jim understands the irix issues and probably
> understands the code.  David understands the structure passing
> problems for AIX, I don't know if he understands the group load
> code.

This code went around to them and Kenner back in January, iirc,
Unfortunately, I seem to have lost whatever mail was exchanged,
but I don't recall that much was said.

If I remember the Irix6 and AIX problems correctly, they use a 
subset of the structure promotion rules that Sparc64 does.  It
is complicated by the fact that I think we currently get the
Irix6 rules wrong.

> We've made several attempts to fix these structure passing problems
> over the years, many of them we've found out later were incorrect.

Yes, it the bits involved are rather fragile, unfortunately.

>   > (2) Attachment 2 disables a check in reload not applicable to Sparc's
>   >     32-bit FP regs when considered with a 64-bit word size.
> Ouch.  I thought Joern has some concerns about this patch, have you
> addressed any of them?

Just now I asked for clarification.

>   > (3) Attachment 3 contains a few unidentified fixes I found in my tree.
>   >     Most of it consists of propogating a change made by Jeff
>   > 
>   >     Wed Dec 31 01:28:37 1997  Jeff Law  <law@cygnus.com>
>   > 
>   > 	* expr.c (expand_expr): For {BITFIELD,COMPONENT,ARRAY}_REF, if the
>   > 	offset's mode is not ptr_mode, convert it.
> I *vaguely* remember this change.  Wow. I can't remember if I was
> trying to solve an Alpha/VMS or some weird mn10200 problem.
> 
> These changes look reasonable to me.

I'll go ahead and commit these, then.


r~

Re: sparc64 changes and generic backend patches

[David Edelsohn]

	I actually saved much of the "move_block_from_reg ignoring
padding" email exchange for anyone's amusement.

	I am not sure which set of patches from that earlier discussion
are being described here.  I mainly remember patches from J"orn which were
intermixed with Henderson's.

	I dislike the emit_group_load/emit_group_store solution using
PARALLEL because it turns PARALLEL into a general escape mechanism for
calls.c and function.c necessitating duplicating a lot of calls.c and
function.c code within those new procedures -- only implemented correctly.
I realize that ABI's defined by GCC using the current, incorrect structure
passing are a significant issue.

	I would rather have a configure/build-time macro choose GCC
compatibility mode instead of using PARALLEL at runtime.  If we punt all
of this functionality to "group", then any bugfix for calls.c or
function.c that is not specific to structure passing needs to be
duplicated in both places.  This is even worse than the current
sched.c/haifa-sched.c maintenance.

	I think the emit_group_load/store changes are correct, but I
don't agree with that form of a solution because what we really are trying
to do is preserve the current structure passing for compatibility and
re-implement the structure passing correctly for those ABIs for which GCC
currently is broken (AIX/PowerOpen, Sparc64, etc.).  I think this could
and should be decided by the GCC target configuration files at buildtime.
No targets need these two calling conventions as a runtime option, which
really is what is possible using this PARALLEL flag/escape mechanism.

David
===============================================================================
David Edelsohn                                      T.J. Watson Research Center
dje@watson.ibm.com                                  P.O. Box 218
+1 914 945 4364 (TL 862)                            Yorktown Heights, NY 10598

Re: sparc64 changes and generic backend patches

[Richard Henderson]

On Sat, May 23, 1998 at 03:13:22PM -0400, David Edelsohn wrote:
> 	I think the emit_group_load/store changes are correct, but I
> don't agree with that form of a solution because what we really are trying
> to do is preserve the current structure passing for compatibility and
> re-implement the structure passing correctly for those ABIs for which GCC
> currently is broken (AIX/PowerOpen, Sparc64, etc.).

Um, I think we are speaking to entirely different issues, summarized
by this sentence.  Namely, I am _not_ trying to preserve any sort of
compatibility, nor am I using it for any sort of "escape mechanism".

The problem for the sparc64 port is that this structure

	struct {
		int a;
		float b;
		float c;
		int d;
		double e;
		long f;
	};

is returned entirely in registers like this:

	%o0	a, left-justified in the 64-bit register
	%f1	b
	%f2	c
	%o1	d, right-justified
	%f4	e
	%o3	f

I can't think of any more natural way to express this very
data-dependant return mechanism than to use a PARALLEL.
	

r~

Re: sparc64 changes and generic backend patches

[David Edelsohn]

>>>>> Richard Henderson writes:

> Um, I think we are speaking to entirely different issues ...
> I am _not_ trying to preserve any sort of
> compatibility, nor am I using it for any sort of "escape mechanism".

	As I said at the beginning of my message, I was not sure which set
of patches from the earlier discussions were being described.  PARALLEL
and emit_group_{store,load} are the correct way to describe some ABIs
which do not have a uniform padding policy, such as Sparc64.  I am not
sure if Irix5 and/or Irix6 need this expressiveness.

	A GCC change to support Irix5 calling conventions broke AIX
calling conventions' uniform padding policy a while ago.  Our earlier
discussion about "move_block_from_reg ignoring padding" included using
your changes as a "catch-all" and noted that move_block_from_reg is called
from the same places as emit_group_store possibly making your changes
applicable there as well.

	I still would like to see the current move_block code and
MUST_PASS_IN_STACK fixed to obey FUNCTION_ARG_PADDING (starting with
J"oern's patches), with some compatibility mode for ABI's which
effectively were defined by current GCC behavior.

Thanks, David

Re: sparc64 changes and generic backend patches

[Joern Rennecke]

> I don't think I understand what you are getting at.  What sort of RTL
> are you thinking of?  The case I am trying to solve is as simple as
> 
> 	(set (reg:SF $f0) (reg:SF 1234))

Your patch does not even apply to this rtl, since

                           && (GET_MODE_SIZE (GET_MODE (operand))
                               > UNITS_PER_WORD)

will evaluate to false.

However, it will apply to stuff like:
(set (reg:DF $f0) (subreg:DF (reg:TI 5678) 1))

or

(set (reg:DF $f0) (subreg:DF (reg:DC 5678) 1))

Re: sparc64 changes and generic backend patches

[Richard Henderson]

On Wed, May 27, 1998 at 02:00:49AM +0100, Joern Rennecke wrote:
> Your patch does not even apply to this rtl, since
> 
>                            && (GET_MODE_SIZE (GET_MODE (operand))
>                                > UNITS_PER_WORD)
> 
> will evaluate to false.

Hmm, you are right.  I'll have to go back and check the cases to
figure out what is really going on.


r~