This is an archive of the discontinued LLVM Phabricator instance.

[ExtVector] Make .even/.odd/.lo/.hi return vectors for single elements.
AbandonedPublic

Authored by fhahn on Oct 19 2020, 6:54 AM.

Details

Summary

Currently the 'swizzle' accessors .even/.odd/.lo/.hi return a scalar
instead of a vector with a single element when the result has a single
element. The current behavior of Clang can lead to unexpected failures
when working with ext_vector_types in templates that paramterize the
number of elements.

In the example below, currently c.even returns a scalar, which is then
converted to char and broadcasted to both elements of b.

typedef uint16_t __attribute__ ((__ext_vector_type__(2))) ushort2;
typedef uint8_t  __attribute__ ((__ext_vector_type__(2))) uchar2;

ushort2 c = 0x0102;
uchar2 b = (uchar2) c.even;

This patch changes the behavior so that swizzels return single element
vectors in that case. This should make the behavior consistent with
vectors with more than 1 element.

Just from looking at the implementation, it seems like the current
behavior is mostly a side-effect of the implementation, where the
handling of element accesses and swizzels is combined.

This patch changes existing behavior and may break some code that relies
on the current behavior. Unfortunately I could not find any
specification for the ext_vector_type so it is hard to tell if the
existing behavior is actually intentional or not. At least there are no
unit tests for the current behavior.

Diff Detail

Event Timeline

fhahn created this revision.Oct 19 2020, 6:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 19 2020, 6:54 AM
Herald added a subscriber: dexonsmith. · View Herald Transcript
fhahn requested review of this revision.Oct 19 2020, 6:54 AM

I'm fairly certain that this will cause some breaks internally at Apple, but I'm also pretty sure that it's a step in the right direction, and we should just sign up to fix any issues it causes.

I guess the counterargument here would be that .x does not produce an extvector(1), and there is at least a plausible argument that .x should be the same as .lo for a two-element vector. I'm not really convinced by this, but it's not totally outrageous.

fhahn abandoned this revision.Jan 18 2021, 6:46 AM

This unfortunately breaks a bunch of existing projects. I'll abandon the change for now, as the gains are probably not worth the cost of breaking backwards compatibility.