This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix eipa_sra AAPCS issue (PR target/65956)

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]