This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix eipa_sra AAPCS issue (PR target/65956)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Alan Lawrence <alan dot lawrence at arm dot com>
- Cc: Richard Biener <rguenther at suse dot de>, Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Martin Jambor <mjambor at suse dot de>
- Date: Thu, 7 May 2015 13:30:30 +0200
- Subject: Re: [PATCH] Fix eipa_sra AAPCS issue (PR target/65956)
- Authentication-results: sourceware.org; auth=none
- References: <5548BC73 dot 8030506 at foss dot arm dot com> <20150505125431 dot GJ1751 at tucnak dot redhat dot com> <5548BF5B dot 9000904 at foss dot arm dot com> <20150505130650 dot GK1751 at tucnak dot redhat dot com> <5548C3AB dot 4050607 at foss dot arm dot com> <20150505142909 dot GP1751 at tucnak dot redhat dot com> <5548D4A8 dot 4070105 at foss dot arm dot com> <5548D4D6 dot 508 at foss dot arm dot com> <0B1BAF2B-4854-45B2-BD35-C8181CBC4936 at suse dot de> <554B4990 dot 8030608 at arm dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, May 07, 2015 at 12:16:32PM +0100, Alan Lawrence wrote:
> So for my two cents, or perhaps three:
>
> (1) It'd be great to have something in the documentation for
> TARGET_FUNCTION_ARG that explains what the contract for the type information
> provided is. Even/especially if some of this is "considered useless" i.e.
> provided on a best effort basis by compiler analysis. (What happens in other
> cases where there are subtyping-like relationships? E.g. genuine C++
> subtyping, or other attributes like const, volatile? I don't imagine that
> any backend's ABI depends on those attributes, but do we want to rule that
> out, e.g. for attributes that don't exist yet?)
Sure, documentation improvements are always welcome.
Yes, const/volatile/__restrict, or various attributes like deprecated and
various others shouldn't be taken into account when deciding on argument (or
return value) passing.
> (2) If all backends were expected to save the function prototype in
> TARGET_INIT_CUMULATIVE_ARGS and use that, it'd be a shame to duplicate that.
> However, it seems this is because other backends don't depend on TYPE_ALIGN.
> It doesn't seem unreasonable for argument passing rules to depend on
> alignment, however.
Most of them don't need that. The type they see in the callee is compatible
with the type they see in the caller (except for when the user is supposed
to ensure that, like K&R calls or va_arg), otherwise supposedly the FEs
should loudly complain.
But, stuff like alignment or various other attributes on scalar types
are considered useless for function calls by the FEs, and so the backends
should treat them IMNSHO too. Thus argument passing rules depending on
alignment of scalars is unreasonable.
BTW, I've checked llvm and it ignores the alignment attribute on scalar
types for argument passing, so the patch I've posted, in addition to
allowing GCC to be compatible with itself, would make it compatible with
clang too in that regard.
> (3) C++11 rules out using __align_as on function arguments, including via a
> typedef. GCC allows __attribute__ aligned on arguments *only via a typedef*.
> Is that how we want it?
Trying to change a GCC extension accepted for many years is not a good idea.
Jakub