[PATCH] D102894: [SystemZ] Emit .gnu_attribute for an externally visible vector abi.

[Ulrich Weigand via Phabricator via llvm-commits]

uweigand added a comment.

> Function return value / parameters: A C function with a vector parameter will be lowered by Clang differently depending on the subtarget vector support. On z13 it may be a <4 x i32>, while on zEC12 it is instead <4 x i32>*. When running instruction selection there would be then no way of telling if <4 x i32>* was a pointer argument or if it was a software ABI vector variable argument. Therefore a function attribute is emitted for each function "has-vector-arg" where as applicable. I guess the alternative might be to actually do this during instruction selection while considering the subtarget vector support presence - if using clang (and not llc), this might be enough. (E.g. if subtarget has vector support, then <4 x i32>* is really a pointer...)

This is probably not even necessary, since even a **pointer** to a vector would still trigger the emission of the gnu_attribute, for the same reason as:

> Global Variables: the lowered types are the same regardless of subtarget, so it is simple to check them late during output.
>
> It seems that GCC emits the vector ABI for global variables. Does this mean that they are stored differently in memory? Should e.g. variable arguments, stack arguments also be considered?

Yes, indeed.  The **alignment** of 128-bit vector types is different between the two ABIs, which means that any use of such types, even via pointers or as struct elements, will trigger ABI differences.

> Emission of the attribute: Managed to do this now as a raw text, which actually works, except with the integrated assembler... Should a new section be created for this somehow..?

For an example of how to handle such things, you might look at emitLocalEntry in the PowerPC target.  You'll need a virtual function in TargetStreamer.h that can be called by the AsmPrinter.cpp code.  Then there need to be two implementations of the virtual function, one for emitting assembler text, and one when directly emitting object files.  Finally, you'll need to handle **reading** the directive in assembler code in the AsmParser.

As to how the actual implementation in object files goes, the "GNU attribute" is a flavor of the ELF "object attribute" feature.   See the documentation here:
https://sourceware.org/binutils/docs-2.36/as/Object-Attributes.html
which refers to the initial specification of the build attribute section in the ARM ELF ABI document, see section "Build Attributes" here:
https://developer.arm.com/documentation/ihi0044/h/?lang=en

This isn't really Z specific, so it should probably be implemented somewhere in common code, if it isn't already ...


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102894/new/

https://reviews.llvm.org/D102894