[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