* What is the type of vector signed + vector unsigned?
@ 2020-12-29 16:33 Richard Sandiford
2020-12-29 17:42 ` Marc Glisse
0 siblings, 1 reply; 5+ messages in thread
From: Richard Sandiford @ 2020-12-29 16:33 UTC (permalink / raw)
To: gcc
Any thoughts on what f should return in the following testcase, given the
usual GNU behaviour of treating signed >> as arithmetic shift right?
typedef int vs4 __attribute__((vector_size(16)));
typedef unsigned int vu4 __attribute__((vector_size(16)));
int
f (void)
{
vs4 x = { -1, -1, -1, -1 };
vu4 y = { 0, 0, 0, 0 };
return ((x + y) >> 1)[0];
}
The C frontend takes the type of x+y from the first operand, so x+y
is signed and f returns -1.
The C++ frontend applies similar rules to x+y as it would to scalars,
with unsigned T having a higher rank than signed T, so x+y is unsigned
and f returns 0x7fffffff.
FWIW, Clang treats x+y as signed, so f returns -1 for both C and C++.
[Was looking at this in the context of PR96377.]
Thanks,
Richard
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: What is the type of vector signed + vector unsigned?
2020-12-29 16:33 What is the type of vector signed + vector unsigned? Richard Sandiford
@ 2020-12-29 17:42 ` Marc Glisse
2020-12-29 18:44 ` Richard Biener
0 siblings, 1 reply; 5+ messages in thread
From: Marc Glisse @ 2020-12-29 17:42 UTC (permalink / raw)
To: Richard Sandiford; +Cc: gcc
On Tue, 29 Dec 2020, Richard Sandiford via Gcc wrote:
> Any thoughts on what f should return in the following testcase, given the
> usual GNU behaviour of treating signed >> as arithmetic shift right?
>
> typedef int vs4 __attribute__((vector_size(16)));
> typedef unsigned int vu4 __attribute__((vector_size(16)));
> int
> f (void)
> {
> vs4 x = { -1, -1, -1, -1 };
> vu4 y = { 0, 0, 0, 0 };
> return ((x + y) >> 1)[0];
> }
>
> The C frontend takes the type of x+y from the first operand, so x+y
> is signed and f returns -1.
Symmetry is an important property of addition in C/C++.
> The C++ frontend applies similar rules to x+y as it would to scalars,
> with unsigned T having a higher rank than signed T, so x+y is unsigned
> and f returns 0x7fffffff.
That looks like the most natural choice.
> FWIW, Clang treats x+y as signed, so f returns -1 for both C and C++.
I think clang follows gcc and uses the type of the first operand.
--
Marc Glisse
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: What is the type of vector signed + vector unsigned?
2020-12-29 17:42 ` Marc Glisse
@ 2020-12-29 18:44 ` Richard Biener
2020-12-29 19:19 ` Alexander Monakov
0 siblings, 1 reply; 5+ messages in thread
From: Richard Biener @ 2020-12-29 18:44 UTC (permalink / raw)
To: gcc, Marc Glisse, Richard Sandiford
On December 29, 2020 6:42:30 PM GMT+01:00, Marc Glisse <marc.glisse@inria.fr> wrote:
>On Tue, 29 Dec 2020, Richard Sandiford via Gcc wrote:
>
>> Any thoughts on what f should return in the following testcase, given
>the
>> usual GNU behaviour of treating signed >> as arithmetic shift right?
>>
>> typedef int vs4 __attribute__((vector_size(16)));
>> typedef unsigned int vu4 __attribute__((vector_size(16)));
>> int
>> f (void)
>> {
>> vs4 x = { -1, -1, -1, -1 };
>> vu4 y = { 0, 0, 0, 0 };
>> return ((x + y) >> 1)[0];
>> }
>>
>> The C frontend takes the type of x+y from the first operand, so x+y
>> is signed and f returns -1.
>
>Symmetry is an important property of addition in C/C++.
>
>> The C++ frontend applies similar rules to x+y as it would to scalars,
>> with unsigned T having a higher rank than signed T, so x+y is
>unsigned
>> and f returns 0x7fffffff.
>
>That looks like the most natural choice.
>
>> FWIW, Clang treats x+y as signed, so f returns -1 for both C and C++.
>
>I think clang follows gcc and uses the type of the first operand.
The desired behavior is the one that OpenCL specifies. If it is implementation defined we should document behavior. I agree symmetry is nice but eventually the current C behavior is what OpenCL specifies.
Richard.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: What is the type of vector signed + vector unsigned?
2020-12-29 18:44 ` Richard Biener
@ 2020-12-29 19:19 ` Alexander Monakov
2021-01-04 13:51 ` Richard Biener
0 siblings, 1 reply; 5+ messages in thread
From: Alexander Monakov @ 2020-12-29 19:19 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc, Marc Glisse, Richard Sandiford
On Tue, 29 Dec 2020, Richard Biener via Gcc wrote:
> >I think clang follows gcc and uses the type of the first operand.
>
> The desired behavior is the one that OpenCL specifies. If it is implementation
> defined we should document behavior. I agree symmetry is nice but eventually
> the current C behavior is what OpenCL specifies.
Where does OpenCL specify that? Checking the 1.2 OpenCL standard I see the
opposite (the code would fail to compile):
6.2.1
Implicit Conversions
[...]
Implicit conversions between built-in vector data types are disallowed.
Alexander
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: What is the type of vector signed + vector unsigned?
2020-12-29 19:19 ` Alexander Monakov
@ 2021-01-04 13:51 ` Richard Biener
0 siblings, 0 replies; 5+ messages in thread
From: Richard Biener @ 2021-01-04 13:51 UTC (permalink / raw)
To: Alexander Monakov; +Cc: GCC Development, Marc Glisse, Richard Sandiford
On Tue, Dec 29, 2020 at 8:19 PM Alexander Monakov <amonakov@ispras.ru> wrote:
>
> On Tue, 29 Dec 2020, Richard Biener via Gcc wrote:
>
> > >I think clang follows gcc and uses the type of the first operand.
> >
> > The desired behavior is the one that OpenCL specifies. If it is implementation
> > defined we should document behavior. I agree symmetry is nice but eventually
> > the current C behavior is what OpenCL specifies.
>
> Where does OpenCL specify that? Checking the 1.2 OpenCL standard I see the
> opposite (the code would fail to compile):
>
> 6.2.1
> Implicit Conversions
>
> [...]
>
> Implicit conversions between built-in vector data types are disallowed.
But then in 6.4 it says operations operate component-wise not saying anything
about type requirements ... which suggests that
int4 i;
uint4 u;
i = i + u;
is valid and is implemented as in C
i.x = i.x + u.x;
i.y = i.y + u.y;
...
and C then doing the appropriate implicit conversions.
So yes, OpenCL doesn't specify implicit conversions and 6.4 suggests that
components are promoted as to C rules which means the current C implementation
matches neither.
Note changing the C frontend can change operation outcome. IIRC we at
some point
decided to allow implicit sign conversions (we don't implement
convert_VECTOR_TYPE
nor clangs convert_vector).
Richard.
> Alexander
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-01-04 13:52 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-29 16:33 What is the type of vector signed + vector unsigned? Richard Sandiford
2020-12-29 17:42 ` Marc Glisse
2020-12-29 18:44 ` Richard Biener
2020-12-29 19:19 ` Alexander Monakov
2021-01-04 13:51 ` Richard Biener
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).