This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: sysv/ms_abi attribute fix, part 5, proper call clobbered registers for ms->sysv calls
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 17 Dec 2008 13:02:38 +0100
- Subject: Re: sysv/ms_abi attribute fix, part 5, proper call clobbered registers for ms->sysv calls
- References: <20081214114533.GH25593@kam.mff.cuni.cz> <m3y6yfa74n.fsf@google.com>
> Jan Hubicka <hubicka@ucw.cz> writes:
>
> > This patch handles it by adding extra patterns that do have SI/DI clobbers that
> > should force reload to do proper thing (I hope).
>
> Using unspec_volatile will disable various optimizations. I don't see
> any reason to use it, as this instruction is not volatile. Just use a
> plain unspec.
I was always under impression that unspec is more or less expression so
it should appear in set or something. unspec_volatile is not that much
worse than foreign ABI function call, but I will update it to unspec.
At least rep;return is modelled same way.
>
>
> > There is one important and
> > ugly hack in the code concerning static variable last_function_call_abi that is
> > used to hold information about ABI to ix86_expand_call form
> > init_cumulative_args. There is currently no way to figure out function
> > type/declaration from ix86_expand_call so there is no way to pass around the
> > ABI information. This is very ugly (and I think it can break when libcalls are
> > needed for argument setup) and any ideas to make this cleaner are welcome.
>
> You only need one bit of information. Encode it into the callarg2
> parameter to ix86_expand_call, which is the value returned by
> function_arg when called with mode == VOIDmode. Currently the value
> encodes the number of registers used for varargs functions. There is
> plenty of room for another bit (actually this is an rtx so you can do
> whatever you like, but sticking to integer encodings seems
> reasonable). While you're at it please clean up the incomprehensible
> nest of ?: operators in function_arg_64.
This is actually good idea ;)
Honza
>
> Ian