[cfe-dev] ABIArgInfo question for RISC-V and hard float abi

[John McCall via cfe-dev]

> On Jun 21, 2018, at 12:48 PM, Roger Ferrer Ibáñez via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> Dear all,
> 
> in RISC-V 32-bit, the base calling convention states that integers
> smaller than 32-bit are sign or zero extended according to their
> "signedness". So something like the definition below
> 
> void foo(short s16, unsigned short u16) { }
> 
> is emitted in IR as
> 
> void @foo(i16 signext %s16, i16 zeroext %u16)
> 
> Now, looking at the RISC-V hard float ABI it states that a case like
> the one below
> 
> struct float_and_short_t {
>   float a;
>   short b;
> }
> 
> where there are enough available registers, 'a' goes into a
> floating-point register and 'b' goes into an integer register and the
> appropriate sign/zero extension happens. Using ABIArgInfo::getExpand
> seems to do exactly what I want except there is no way to state that
> some of the expanded types may need to be sign/zero extended.
> 
> So, a case like the following
> 
> struct float_and_short_t
> {
>    float a;
>    short b;
> };
> void bar(struct float_and_short_t fs, short i16) { }
> 
> the emitted IR is
> 
> void @bar(float %fs.0, i16 %fs.1, i16 signext %i16)
> 
> where %fs.1 lacks the attribute signext (%i16 does correctly have it).
> 
> My understanding is that signext/zeroext are attributes of the
> arguments not llvm;:Type. This would exclude
> ABIArgInfo::getCoerceAndExpand. Reading the code in CodeGen/CGCall.cpp
> apparently only ABIArgInfo::getExtend (not to be confused with
> getExpand) is able to set signext/zeroext. I haven't found any example
> in CodeGen/TargetInfo.cpp for some other target where a similar case
> happens.
> 
> I wonder what would be the best way to achieve this. In this case I
> know exactly the size of the expansion so I could define a "companion"
> sequence (i.e. a smallvector or similar) that relates to every element
> expanded and allows me to set the proper attribute and set it as an
> attribute of the ABIArgInfo. Perhaps there is a better way.

I think it would be reasonable to generalize what can be done by
CoerceAndExpand to include possibly adding attributes to the components.
We might have to think about how to do that.

I would like to remove Expand entirely in favor of CoerceAndExpand, which
is strictly more flexible, so please don't add anything to it.

John.