ABIArgInfo question for RISC-V and hard float abi

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

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.

Thoughts, suggestions?

Thanks a lot,

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.


Hi John,

thanks. I'll look into CoerceAndExpand and see how can I fit the
information I need there.

Kind regards,