[cfe-dev] Matrix Support in Clang
John McCall via cfe-dev
cfe-dev at lists.llvm.org
Thu Apr 2 09:32:12 PDT 2020
On 2 Apr 2020, at 9:47, Florian Hahn wrote:
>> On Apr 1, 2020, at 20:48, Stephen Canon <scanon at apple.com> wrote:
>>> On Apr 1, 2020, at 1:23 PM, John McCall via cfe-dev
>>> <cfe-dev at lists.llvm.org> wrote:
>>>> On 1 Apr 2020, at 13:15, Florian Hahn wrote:
>>>> I agree that ideally we would not allow mis-matched binary
>>>> operations to avoid surprises. It looks like the existing vector
>>>> type does not perform implicit conversion for binary operations
>>>> with 2 vector operands (unless the there is a type mis-match and
>>>> the data size matches, then the LHS type is chosen). For binary ops
>>>> with vector and scalar operands, the scalar operand is converted to
>>>> the vector element type. So short4 + short4 -> short4, short4 + int
>>>> -> short4, short4 + int4 -> invalid.
>>>> Given that precedence, I think we should opt for not providing
>>>> conversions for binary operators with two matrix operands. For the
>>>> matrix and scalar versions, we could convert to the element type
>>>> automatically for convenience. But at that point, the gain is
>>>> probably quite small and it would be simpler to don’t do
>>>> conversions in any case. Does that sound reasonable?
>>> I think converting scalars is a necessary convenience in C given
>>> that e.g. literals are normally of type int, but yes, I think it’s
>>> fine to not implicitly convert matrices as long as you have a way to
>>> convert them explicitly.
> Converting them explicitly should be covered by the standard
> conversion rules, right?
Do you want matrices to be implicitly convertible in non-operator
contexts? Like, if you assign a `float4x4` to an `int4x4`, should that
implicitly convert the elements or be ill-formed?
>> For matrix operations implicit scalar conversions will be less
>> important than they are for vectors, but they turned out to be really
>> critical to have for vector programming. It may make sense to have
>> them for matrices as well.
>> The main issue for vectors is that there’s no way to get a sub-int
>> literal in C (i.e. there’s no i8 suffix). This meant that simple
>> vector code like, e.g.:
>> uchar16 a, b;
>> uchar16 c = a & 0xf | b << 4;
>> Had to be written as:
>> uchar16 c = a & (uchar16)0xf | b << (uchar16)4;
>> Which, well, it really sucked before we added the conversion rule.
>> This sort of thing is less common for matrix math than vector math,
>> but it probably makes sense to match the semantics for convenience
>> and consistency; there haven’t really been a lot of drawbacks to
>> the vector semantics.
>> There should be no implicit conversions for matrix operands (and
>> certainly not the C usual arithmetic conversions; approximately no
>> one wants that behavior).
> Thanks, I’ve updated the arithmetic conversion rules in
> https://reviews.llvm.org/D76612 with the text below:
> * If both operands are of matrix type, no arithmetic conversion is
> * If one operand is of matrix type and the other operand is of an
> integer or
> floating point type, convert the integer or floating point operand
> to the
> underlying element type of the operand of matrix type.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev