• Bruce Carneal (21/21) Sep 13 2022 Currently applying an @restrict attribute to a slice argument
• kinke (6/16) Sep 13 2022 Yeah that would definitely be nice. - I guess this would require
• Bruce Carneal (12/19) Sep 29 2022 Following up:
• Guillaume Piolat (5/7) Oct 01 2022 Not in production code, but it can unlock some opts in:

Bruce Carneal <bcarneal gmail.com> writes:

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

```d
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.

kinke <noone nowhere.com> writes:

On Tuesday, 13 September 2022 at 18:56:10 UTC, Bruce Carneal 
wrote:
 Currently applying an  restrict attribute to a slice argument 
 results in something like this from ldc:

 ```d
 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.

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.

Bruce Carneal <bcarneal gmail.com> writes:

On Tuesday, 13 September 2022 at 19:39:44 UTC, kinke wrote:
 On Tuesday, 13 September 2022 at 18:56:10 UTC, Bruce Carneal 
 wrote:
 ...

 Might this be upgraded to match gdc's current behavior on 
 godbolt? (allow  restrict for both pointers and slice)

 Yeah that would definitely be nice...

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.

Guillaume Piolat <first.last spam.org> writes:

On Friday, 30 September 2022 at 03:18:46 UTC, Bruce Carneal wrote:
 2) I understand pOnce has seen a few (modest?) gains in his 
 SIMD code using  restrict.

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.