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.

On Tuesday, 30 July 2024 at 16:50:05 UTC, Bruce Carneal wrote:

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).

On Wednesday, 31 July 2024 at 10:16:57 UTC, kinke wrote:

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.

On Tuesday, 30 July 2024 at 16:50:05 UTC, cookie clicker 2 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.

On Thursday, 8 August 2024 at 07:33:37 UTC, NadiaEira wrote:

AI that we deserved :D

On Wednesday, 31 July 2024 at 10:16:57 UTC, kinke wrote:

So do you have any other solutions to the problems people are facing?

On Thursday, 12 September 2024 at 16:20:34 UTC, sternwaytrysail wrote:

You might consider other approaches, such as using pointer-based methods or reference counting to manage memory safely.

On Wednesday, 31 July 2024 at 10:16:57 UTC, kinke wrote:

For performance-critical functions, especially in environments like auto-vectorization and DCompute, it's crucial to maintain clarity while ensuring optimal performance. While nested functions can be a workaround, they might complicate the code when dealing with multiple inputs and outputs. If you’re considering an implementation change, it’s wise to weigh the benefits against potential ABI changes and the complexity it might introduce. Keeping the code maintainable while optimizing performance is a delicate balance.