• Bruce Carneal (7/7) Jul 30 Would an @restrict function attribute that applied to all ptr and
• kinke (5/7) Jul 31 I don't think it'd be a good idea in general, and it wouldn't
• Bruce Carneal (13/20) Jul 31 Not a good idea eh? Well, using the alternative available today
• NadiaEira (8/15) Aug 08 It sounds like the @restrict function attribute would be really
• Sergey (2/8) Aug 08 AI that we deserved :D

Bruce Carneal <bcarneal gmail.com> writes:

Would an  restrict function attribute that applied to all ptr and 
slice arguments be hard to implement?

I'd use this on most if not all of my performance critical 'leaf' 
functions for both auto-vec and dcompute environments.  Nested 
functions accepting individual  restrict pointer arguments are an 
OK alternative but when working with multiple inputs and outputs 
things get a little tangled.

kinke <noone nowhere.com> writes:

On Tuesday, 30 July 2024 at 16:50:05 UTC, Bruce Carneal wrote:
 Would an  restrict function attribute that applied to all ptr 
 and slice arguments be hard to implement?

I don't think it'd be a good idea in general, and it wouldn't 
simplify the implementation of ` restrict` for slices at all, 
which would most likely need an ABI change 
(https://forum.dlang.org/post/vgfxycegiagawfxaenwg forum.dlang.org).

Bruce Carneal <bcarneal gmail.com> writes:

On Wednesday, 31 July 2024 at 10:16:57 UTC, kinke wrote:
 On Tuesday, 30 July 2024 at 16:50:05 UTC, Bruce Carneal wrote:
 Would an  restrict function attribute that applied to all ptr 
 and slice arguments be hard to implement?

 I don't think it'd be a good idea in general, and it wouldn't 
 simplify the implementation of ` restrict` for slices at all, 
 which would most likely need an ABI change 
 (https://forum.dlang.org/post/vgfxycegiagawfxaenwg forum.dlang.org).

Not a good idea eh?  Well, using the alternative available today 
extensively I disagree.  The use case is for  safe performance 
critical programming where the compiler can not readily determine 
the aliasing (you'll see some code expansion in current LDC for 
very simple cases where the generated code first proves 
independence).

Still, thanks for the response.  I'll stick with the 
manual/ trusted nested functions workaround.  It is *much* better 
than nothing, having allowed me to ditch my entire explicit SIMD 
code base.  Well, almost everything.  I still have need for an 
efficient mapping of conditionals to bit vectors and don't know 
how to do that without dropping into SIMD land.

NadiaEira <nadiaeira00 gmail.com> writes:

On Tuesday, 30 July 2024 at 16:50:05 UTC, [cookie clicker 
2](https://cookieclicker-2.com) wrote:
 Would an  restrict function attribute that applied to all ptr 
 and slice arguments be hard to implement?

 I'd use this on most if not all of my performance critical 
 'leaf' functions for both auto-vec and dcompute environments.  
 Nested functions accepting individual  restrict pointer 
 arguments are an OK alternative but when working with multiple 
 inputs and outputs things get a little tangled.

It sounds like the  restrict function attribute would be really 
useful for optimizing performance in your code. Implementing it 
for all ptr and slice arguments could definitely simplify things, 
especially for complex functions with multiple inputs and 
outputs. It's a great idea to consider for both auto-vec and 
dcompute environments.

Sergey <kornburn yandex.ru> writes:

On Thursday, 8 August 2024 at 07:33:37 UTC, NadiaEira wrote:
 It sounds like the  restrict function attribute would be really 
 useful for optimizing performance in your code. Implementing it 
 for all ptr and slice arguments could definitely simplify 
 things, especially for complex functions with multiple inputs 
 and outputs. It's a great idea to consider for both auto-vec 
 and dcompute environments.

AI that we deserved :D