C++ Logo


Advanced search

Re: [std-proposals] SIMD by just operating on 2 arrays

From: Edward Catmur <ecatmur_at_[hidden]>
Date: Wed, 12 Apr 2023 14:12:11 -0300
On Wed, 12 Apr 2023, 13:04 samuel ammonius via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Wed, Apr 12, 2023 at 12:57 PM Giuseppe D'Angelo via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>> Again, what's "that"? The decay?
> Yeah, by "that" I was referring to the decay. It is UB, right?

Decaying an array is not UB. UB occurs when arithmetic between pointers
involves pointers that do not point to elements of the same array.

> It is certainly a huge change. What should `+a` do? This is _widely_
>> used as an idiomatic "please decay". Should it stop decaying and give
>> back the float[4] unchanged?
>> What should `a + 3` do? This has well defined semantics and it's _super
>> widely_ used. Are you suggesting to break that code?
> I've never seen code that adds to an array to decay it in my life.

It's a very common idiom to get a pointer to the 4th element of the array.

Anyway, I wasn't proposing that adding a number to the array adds it to
> every element (although I would have if I thought of it, but if it creates
> issues then lets not add it).

Then we have a confusingly incomplete feature.

> And it's not just about the operators themselves: how do you pass a SIMD
>> float[4] to a function? How do you return one from a function? Today a
>> function like `void f(float[4])` has a precise meaning (that has nothing
>> to do with SIMD).
> Functions that take arrays can just perform SIMD on the passed array.
> About returning SIMD, it's the same issue as returning arrays. I don't know
> why we can't return arrays since computers are perfectly capable of doing
> that.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

Received on 2023-04-12 17:12:26