3

If I get it correctly, __declspec(noalias) tells the compiler that none of the pointers passed as parameters is aliased.

__declspec(noalias) void multiply(float * a, float * b, float * c)
{
    ...
}

Said differently, if I’m not mistaken , it’s exactly equivalent to calling __restrict on every parameter of pointer type. But is there a way to do it without changing all the function calls? Ideally, I would replace that __declspec(noalias) with a preprocessor definition.

Mat
  • 202,337
  • 40
  • 393
  • 406
qdii
  • 12,505
  • 10
  • 59
  • 116

3 Answers3

4

I think you're interpreting noalias incorrectly; it is not the same as specifying __restrict on each parameter. In the example you reference from MSDN, it means that a, b, and c don't modify or reference any global state (of the current compilation unit), but they are free to alias one another. You could also specify __restrict on each one to indicate that they do not alias each other. I'm not sure why you mention changing all the function calls in this scenario; as long as no caller aliases the arguments, nothing changes at the call site. You should review all the calls, but they needn't change unless you need to remove aliasing. Specifically, __restrict is not needed at the call site.

The only analogue in GCC would be to specify __restrict (or more commonly for GCC, __restrict__) on any global pointer variable declarations in the same source file (which are of compatible types). See here about file-scope restrict-qualified pointers. Of course, there's no guarantee that GCC will behave any differently, since restrict is often considered only at function scope. Microsoft clearly introduced noalias to enable a specific optimization they introduced.

Long story short, there's no macro trick here (aside from the one mentioned by R to ignore __declspec() entirely on GCC). The best you can do is add __restrict to any non-aliased pointer parameter and global variable declarations.

Trevor Robinson
  • 15,694
  • 5
  • 73
  • 72
2

The correct The closest gcc/clang analogue for __declspec(noalias) is __attribute__((const)) - not restrict: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-const-function-attribute

noalias says more than "the arguments do not reference globals": it says the function does not access or modify global state, through the arguments or not. noalias is a rather unfortunate choice of terminology.

Note @NateEldredge's comment for an important difference between the two.

Ofek Shilon
  • 14,734
  • 5
  • 67
  • 101
  • Still, "Note that a function that has pointer arguments and examines the data pointed to must not be declared const if the pointed-to data might change between successive invocations of the function". Is that true of `noalias` too? – Nate Eldredge Jun 06 '23 at 16:11
  • 1
    @NateEldredge Thank you! You're right, I wasn't aware of this attribute-const restriction. Just tested it, and indeed gcc reduces multiple calls to a single one: https://godbolt.org/z/j61318Ynj , and msvc doesn't: https://godbolt.org/z/f7Ysdzbq8. – Ofek Shilon Jun 06 '23 at 16:55
  • @NateEldredge [`__attribute__((pure))`](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-pure-function-attribute) might work: "The `pure` attribute imposes similar but looser restrictions on a function’s definition than the `const` attribute: ..." – Andrew Henle Jun 06 '23 at 17:04
  • @AndrewHenle MS docs say "noalias means that a function call doesn't modify *or reference* visible global state". This is much closer to `const` than `pure`. – Ofek Shilon Jun 06 '23 at 17:13
  • @OfekShilon But if `const` is too restrictive from a caller perspective, `pure`'s "does not affect their return value or the observable state of the program" *might* suffice from the caller's viewpoint, even if it is a looser restriction on what the actual function *could* do. – Andrew Henle Jun 06 '23 at 17:26
-1

Just #define __declspec(x) (to a blank definition). Omitting noalias/restrict will not make any change to the behavior of a correct program. All it does is create additional (usually very minor, with current compiler technology) opportunities for the compiler to optimize.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • +1 for the idea, but I can’t accept this as a solution. The context is video gaming, `__restrict` is not an option :) – qdii Mar 10 '12 at 23:31
  • Have you measured the difference in performance with/without "noalias" on Windows? Premature optimization is the root of all evil. The time you're wasting trying to find a solution to this problem could probably be better spent just optimizing higher-level inefficiencies in the code... – R.. GitHub STOP HELPING ICE Mar 10 '12 at 23:57
  • 5
    I couldn’t agree more with you on that point. But even if the optimization was pointless in my case, I could imagine that a future reader would really need a solution for that. – qdii Mar 22 '12 at 11:51