
12

On 2 Apr 2020, at 16:17, Florian Hahn wrote:
> > On Apr 2, 2020, at 17:32, John McCall < [hidden email]> wrote:
>>
>> On 2 Apr 2020, at 9:47, Florian Hahn wrote:
>>
>> On Apr 1, 2020, at 20:48, Stephen Canon < [hidden email]> wrote:
>>
>> On Apr 1, 2020, at 1:23 PM, John McCall via cfedev
>> < [hidden email]> wrote:
>>
>> On 1 Apr 2020, at 13:15, Florian Hahn wrote:
>> I agree that ideally we would not allow mismatched 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 mismatch 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 nonoperator
>> contexts? Like, if you assign a float4x4 to an int4x4, should that
>> implicitly convert the elements or be illformed?
>>
>>
> I think the current formulation allows for implicit conversions for
> matrixes.
>
> But given the recent changes in the arithmetic context, it might be
> better to only allow explicit conversions. Having implicit conversions
> for nonoperator contexts and not in operator contexts seems a bit
> inconsistent. I think we should keep the conversion rules based on the
> element types, but limit them to explicit conversions. Does that make
> sense?\
That makes sense to me. If it’s actually a usability issue in
practice, we can revisit, but I suspect that if we start strict we’ll
avoid that.
John.
_______________________________________________
cfedev mailing list
[hidden email]
https://lists.llvm.org/cgibin/mailman/listinfo/cfedev


On 2 Apr 2020, at 16:17, Florian Hahn wrote:> On Apr 2, 2020, at 17:32, John McCall <[hidden email]> wrote:
On 1 Apr 2020, at 13:15, Florian Hahn wrote: I agree that ideally we would not allow mismatched 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 mismatch 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 nonoperator contexts? Like, if you assign a float4x4 to an int4x4, should that implicitly convert the elements or be illformed?
I think the current formulation allows for implicit conversions for matrixes.
But given the recent changes in the arithmetic context, it might be better to only allow explicit conversions. Having implicit conversions for nonoperator contexts and not in operator contexts seems a bit inconsistent. I think we should keep the conversion rules based on the element types, but limit them to explicit conversions. Does that make sense?\
That makes sense to me. If it’s actually a usability issue in practice, we can revisit, but I suspect that if we start strict we’ll avoid that.
The standard conversions are extended as follows, with the exception that for matrix types, standard conversions are not permissible for assignments.
Not sure if that’s the best way to put it, but hopefully the intention is clear.
Cheers, Florian _______________________________________________
cfedev mailing list
[hidden email]
https://lists.llvm.org/cgibin/mailman/listinfo/cfedev


On 3 Apr 2020, at 14:17, Florian Hahn wrote:
> > On Apr 2, 2020, at 21:49, John McCall < [hidden email]> wrote:
>> On 2 Apr 2020, at 16:17, Florian Hahn wrote:
>>
>>>> On Apr 2, 2020, at 17:32, John McCall < [hidden email]> wrote:
>>>>
>>>> On 1 Apr 2020, at 13:15, Florian Hahn wrote:
>>>> I agree that ideally we would not allow mismatched 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 mismatch 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 nonoperator
>>>> contexts? Like, if you assign a float4x4 to an int4x4, should that
>>>> implicitly convert the elements or be illformed?
>>>>
>>>>
>>> I think the current formulation allows for implicit conversions for
>>> matrixes.
>>>
>>> But given the recent changes in the arithmetic context, it might be
>>> better to only allow explicit conversions. Having implicit
>>> conversions for nonoperator contexts and not in operator contexts
>>> seems a bit inconsistent. I think we should keep the conversion
>>> rules based on the element types, but limit them to explicit
>>> conversions. Does that make sense?\
>>
>> That makes sense to me. If it’s actually a usability issue in
>> practice, we can revisit, but I suspect that if we start strict
>> we’ll avoid that.
>>
>>
>
> I’ve updated the Standard Conversion section in
> https://reviews.llvm.org/D76612 with the following:
>
> The standard conversions are extended as follows, with the exception
> that for matrix types, standard conversions are not permissible for
> assignments.
>
> Not sure if that’s the best way to put it, but hopefully the
> intention is clear.
Yeah, that’s probably a bit misleading. I’d say:
The standard conversions are extended as follows. Note that these
conversions are intentionally not listed as satisfying the constraints
for assignment, which is to say, they are only permitted as explicit
casts, not as implicit conversions.
John.
_______________________________________________
cfedev mailing list
[hidden email]
https://lists.llvm.org/cgibin/mailman/listinfo/cfedev


On 3 Apr 2020, at 14:17, Florian Hahn wrote:> On Apr 2, 2020, at 21:49, John McCall <[hidden email]> wrote:
On 2 Apr 2020, at 16:17, Florian Hahn wrote:
On Apr 2, 2020, at 17:32, John McCall <[hidden email]> wrote:
On 1 Apr 2020, at 13:15, Florian Hahn wrote: I agree that ideally we would not allow mismatched 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 mismatch 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 nonoperator contexts? Like, if you assign a float4x4 to an int4x4, should that implicitly convert the elements or be illformed?
I think the current formulation allows for implicit conversions for matrixes.
But given the recent changes in the arithmetic context, it might be better to only allow explicit conversions. Having implicit conversions for nonoperator contexts and not in operator contexts seems a bit inconsistent. I think we should keep the conversion rules based on the element types, but limit them to explicit conversions. Does that make sense?\
That makes sense to me. If it’s actually a usability issue in practice, we can revisit, but I suspect that if we start strict we’ll avoid that.
I’ve updated the Standard Conversion section in https://reviews.llvm.org/D76612 with the following:
The standard conversions are extended as follows, with the exception that for matrix types, standard conversions are not permissible for assignments.
Not sure if that’s the best way to put it, but hopefully the intention is clear.
Yeah, that’s probably a bit misleading. I’d say: The standard conversions are extended as follows. Note that these conversions are intentionally not listed as satisfying the constraints for assignment, which is to say, they are only permitted as explicit casts, not as implicit conversions.
Thanks John, that’s much clearer! I’ve updated the wording.
I think https://reviews.llvm.org/D76612 should now reflect the latest version of the spec, with all comments addressed or corresponding future work items added. AFAIU the remaining TODOs can be addressed after landing the initial version.
Cheers, Florian _______________________________________________
cfedev mailing list
[hidden email]
https://lists.llvm.org/cgibin/mailman/listinfo/cfedev


In reply to this post by David Blaikie via cfedev
Greeting!
Right here I send you a notification concerning our agreement obligations. If we won't obtain the reply in 3 days, we will be forced to discard the contract. To view the specification, please look at the file attached.
> On Apr 1, 2020, at 20:48, Stephen Canon wrote:
>
>> On Apr 1, 2020, at 1:23 PM, John McCall via cfedev wrote:
>>
>>> On 1 Apr 2020, at 13:15, Florian Hahn wrote:
>>> I agree that ideally we would not allow mismatched 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 mismatch 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?
> 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 subint 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 performed.
* 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.
Cheers,
Florian
_______________________________________________
cfedev mailing list
[hidden email]
https://lists.llvm.org/cgibin/mailman/listinfo/cfedev
_______________________________________________
cfedev mailing list
[hidden email]
https://lists.llvm.org/cgibin/mailman/listinfo/cfedev

12
