Richard Biener wrote:
On May 5, 2015 4:33:58 PM GMT+02:00, Richard Earnshaw
<richard.earns...@foss.arm.com> wrote:
On 05/05/15 15:33, Richard Earnshaw wrote:
On 05/05/15 15:29, Jakub Jelinek wrote:
On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote:
On 05/05/15 14:06, Jakub Jelinek wrote:
For the middle-end, the TYPE_ALIGN info on expression types is
considered
useless, you can get there anything. There is no conversion rule
to what
you get for myalignedint + int, or (myalignedint) int, or (int)
myalignedint, etc.
create a consistent view of the values passed into the back-end?
It
seems to me that at present the back-end has to be psychic as to
what is
really happening.
No, the backend just shouldn't consider TYPE_ALIGN on the scalars,
and it
seems only arm ever looks at that.
Nothing in the specification for TARGET_FUNCTION_ARG (or any of the
related functions) makes any mention of this...
While this requirement isn't documented, it is clearly common sense
or at
least something any kind of testing would reveal immediately.
Then clearly no such tests exist in the testsuite :-(
Or, more precisely, no such tests existed in 2008, when the code went
in.
That just means that the code was the first that make this matter.
BTW, what do other compilers do (I suppose llvm supports the gcc extensions for
alignment)? Can llvm and gcc interoperate properly here? Do the cited
testcases work with llvm?
Richard.
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?)
(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.
(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?
--Alan
