Message-ID: <19990701171239.A12674@tabor.ta.jcu.cz>
Date: Thu, 1 Jul 1999 17:12:39 +0200
From: Jan Hubicka <hubicka AT ta DOT jcu DOT cz>
To: djgpp-workers AT delorie DOT com
Subject: Re: Regparm patch.
References: <19990630140207 DOT 12975 AT atrey DOT karlin DOT mff DOT cuni DOT cz> <199906301402 DOT KAA04136 AT indy DOT delorie DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93i
In-Reply-To: <199906301402.KAA04136@indy.delorie.com>; from DJ Delorie on Wed, Jun 30, 1999 at 10:02:55AM -0400
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Wed, Jun 30, 1999 at 10:02:55AM -0400, DJ Delorie wrote:
> 
> Rather than replacing all the .S files with .c files, please add
> macros to some global asm macros file to access the parameters, like
> ARG0, ARG1, etc, for as many args as you need.  Or, use conditional
I was thinking about this originally, problem is that making such macros
is quite complex. For example when arg0 is in register, movl ARG0, %eax
will result in movl %eax, %eax and thats not very nice.
Macros like MOV_ARG0_TO_EAX are ugly as well IMO.
Also you will have to take care for moving thinks in right order to 
not overwrite some future parameter. This for example is very problematic
in the outport functions, where registers needs to be exhanged.
This can bring lots of stupid bugs
and because mregparm interface can change in near future (for example to support
more than 3 registers), we would have to re-make this job.
> assembles like you did in a few cases.  I get a bad feeling about such
I was a bit affraid of this rewrite as well, thats why I was trying
to keep assembler version, where the C one was really weird, or changes
necesary very small (one or no parameter functions)
> complex inline asms with so many parameters; I worry that gcc may
> mis-optimize around it and end up corrupting a register in some future
> release.
The design flaw in reload that was causing gcc to missoptimize code in
high register presure is gone now (and thats why we can experiment with
the mregparm stuff). This bug still may happen in rare cases _only_ with
regparm enabled (at least no other testcase is known and there is purpose
to believe so), but compiler chrash is the result, not incorrect code.
This happended in the outport functions and can be trivially fixed.

Missoptimization may not happen in the old version w/o the -mregparm stuff
as well, because this bug happended only in over combined 
(or -fschedule-insnsized) code, where lifetimes
of hard registers was enlarged and some other instruction requiring
this register was placed between them. I hope they may not happen here,
because surrounding C code is usually very trivial and don't include instructions like divide or variable shift that was forcing this problem.

So I would like to stay with the .c versions if possible...
Last advantage of asm statements is, that libc is now functional with
pascal calling conventions as well. I am not sure if it is at all usefull,
but it is interesting side efect.

Honza