[llvm-dev] CreateNot when the operand is a Scalable Vector

[Roger Ferrer Ibáñez via llvm-dev]

Hi,

apologies. I totally missed the ConstantDataVector::getSplat
<https://llvm.org/doxygen/classllvm_1_1ConstantDataVector.html#a44124e702dc442346bd6202bb03e593b>
.

Kind regards



Missatge de Roger Ferrer Ibáñez <rofirrim at gmail.com> del dia dt., 26 de
nov. 2019 a les 18:43:

> Hi all,
>
> IRBuilder has a method CreateNot which may invoke
> BinaryOperator::CreateNot. However there isn't actually a `not` operation
> in LLVM IR so BinaryOperator::CreateNot acts as a helper by creating a
> `xor` against a suitable constant of all ones, the exact nature of such
> constant depends on the operand and may end being a (fixed-size) vector.
>
> However the creation of the "all ones" constant is not feasible when the
> operand we want to `not` is a scalable vector (vector constants are
> described by extension).
>
> I guess we can change IRBuilder::CreateNot to check this case and emit the
> LLVM IR we customarily use for splats via IRBuilder::CreateVectorSplat so
> we get a value of a scalable vector of "all ones".
>
> However, a cursory `grep` reveals a few direct users of
> BinaryOperator::CreateNot (note that this is a pessimistic stance as not
> all of them may end being invoked on vectors) so we might want to do better
> here.
>
> I don't have a good solution here but I will assume that introducing a
> "splatted constant" in LLVM IR is not desirable.
>
> One option may be asserting in BinaryOperator::CreateNot (and other
> helpers impacted by the same issue). This seems a bit hostile for users of
> BinaryOperator.
>
> Maybe move around the code in IRBuilder::CreateVectorSplat so it is
> useable outside IRBuilder and then use it in BinaryOperator::CreateNot?
>
> Perhaps there are better alternatives already used in practice for those
> working with scalable vectors?
>
> Thanks a lot,
>
> --
> Roger Ferrer Ibáñez
>


-- 
Roger Ferrer Ibáñez
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191126/acceaefe/attachment.html>