[llvm-dev] Instruction selection pattern for intrinsic returning llvm_any_ty

Mikael Holmén via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 30 04:13:57 PDT 2016


Hi,

>>> The intrinsic itself should define multiple IR outputs rather than
>>> using any ty.
>>
>> But the intrinsic returns a record so in the input ll-file it is one
>> result
>>
>> %_tmp3 = call %rec6 @llvm.phx.divm.u16.rec6(i16 %_tmp1, i16 %_tmp2)
>>
>> and then the return value struct is lowered to two i16:s by
>
> This seems like a strange way to do it. Do you need it to be an
> arbitrary struct type for some reason?

Not really.
At the C level we have

typedef struct {
     __u16_t quotient;
     __u16_t remainder;
} __divm16_t;

__divm16_t __divm_u16(__u16_t, __u16_t);

and our frontend translates calls to this function to calls to our intrisic

%_tmp3 = call %rec6 @llvm.phx.divm.u16.rec6(i16 %_tmp1, i16 %_tmp2)

and then we translate it tou our hardware instruction divm (which 
produces two i16 values).

We could probably change our frontend so the intrinsic produces two 
values rather than the struct, but if tablegen will not accept a pattern 
with multiple results (which I've no idea if it does or not, but at 
least I don't know what the syntax would be for it) we won't gain 
anything from this anyway.

The code we have works, only that we need to handle all instrisics like 
this "manually" in ISelDAGToDAG and I would prefer to write patterns for 
the selection instead, but it seems it's not very straight forward, if 
even possible.

Thanks for your help,
Mikael


> Having multiple result types that
> expand into a struct would be more normal
>
>
>>
>> SelectionDAGISel::SelectBasicBlock:
>>
>>  // Lower the instructions. If a call is emitted as a tail call, cease
>> emitting
>>  // nodes for this block.
>>  for (BasicBlock::const_iterator I = Begin; I != End &&
>> !SDB->HasTailCall; ++I)
>>    SDB->visit(*I);
>>
>> just prior to the selection.
>>
>>> I’m also not sure if tablegen currently supports patterns with
>>> multiple results
>>
>> Yes, me neither...
>>
>> /Mikael
>>
>>>
>>> -Matt
>



More information about the llvm-dev mailing list