This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, MIPS] Fix PR target/68273, passing args in wrong regs
- From: Steve Ellcey <sellcey at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 1 Feb 2016 13:50:39 -0800
- Subject: Re: [Patch, MIPS] Fix PR target/68273, passing args in wrong regs
- Authentication-results: sourceware.org; auth=none
- References: <a80cfc11-c2a6-4142-b66f-a522f227d6ba at BAMAIL02 dot ba dot imgtec dot org> <87egczwclj dot fsf at googlemail dot com>
- Reply-to: <sellcey at imgtec dot com>
On Sat, 2016-01-30 at 11:06 +0000, Richard Sandiford wrote:
> I'm not sure this patch is safe. The received wisdom used to be that
> ABIs should be defined in terms of types, not modes, since types
> represent the source code while modes are an internal GCC concept
> that could change over time (although in practice the barrier for
> that is pretty high).
>
> The patch that introduced the line being patched was part of a series
> that fixed ABI incompatibilities with MIPSpro, and IIRC some of the
> incompatibilties really were due to us looking at modes when we should
> have been looking at types.
My main reason for looking at mode instead of type for non-aggregates
was because of argument promotion. When I looked at a function with a
char argument, the type was char but the mode was SI. Now I could still
use the alignment of char (1 byte) since it would get extended to 4
bytes in mips_function_arg_boundary by:
if (alignment < PARM_BOUNDARY)
alignment = PARM_BOUNDARY;
But it still seemed a bit 'wrong' to me. Maybe something in the
front/middle ends should be updating the type to match any argument
promotion that is being done?
Steve Ellcey
sellcey@imgtec.com