Currently applying an @restrict attribute to a slice argument results in something like this from ldc:

Attribute 'noalias' applied to incompatible type! i16 ({ i64, i16* })* ...

Might this be upgraded to match gdc's current behavior on godbolt? (allow @restrict for both pointers and slices) I don't see a downside apart from the, hopefully modest, work required to get it in place. On the upside, it would be nice to be able to use @restrict with somewhat safer, idiomatic code.

For reference, I've observed that @restrict helps the auto vectorizer in both gdc and ldc. At a minimum it eliminates all the "lets check if these are overlapping" code. It may help keep the auto-vectorizers engaged with more involved kernels. I have nothing to report on that yet but it makes sense as the costs are lowered somewhat and the analysis is simplified.

Assuming @restrict applies to slices in the future, the idiomatic form might be to attach @restrict to output buffer arguments passed to @trusted routines. As you'd expect, both compilers "do the right thing" when read-only source arguments remain unadorned.

On Tuesday, 13 September 2022 at 18:56:10 UTC, Bruce Carneal wrote:

Attribute 'noalias' applied to incompatible type! i16 ({ i64, i16* })* ...

Yeah that would definitely be nice. - I guess this would require passing slices as 2 separate arguments in LLVM IR, which probably messes with a bunch of assumptions of a 1:1 mapping of D params to IR params - so probably not that simple.

On Tuesday, 13 September 2022 at 19:39:44 UTC, kinke wrote:

Following up:

1. gdc trunk on godbolt accepted @restrict on slice argument but ignored it in code gen. IIUC I believe Iain thinks this should error out, at least for now.

2. I understand pOnce has seen a few (modest?) gains in his SIMD code using @restrict.

3. Calling nested functions with @restrict pointers coming from slice args to an @trusted outer function that does all the bounds checking is an agreeable workaround so ... very nice to have @restrict slices but their absence does not usher in the apocalypse.

On Friday, 30 September 2022 at 03:18:46 UTC, Bruce Carneal wrote:

Not in production code, but it can unlock some opts in: https://d.godbolt.org/z/qvW9PfssM
Personally I would prefer some "diagnostics" output from autovectorizer that says which are the loop dependencies.