September 13

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.

September 13

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:

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.