Share via

restrict(amp) restrictions part 7 of N – volatile and miscellaneous forbidden operators and statements

  • Article

This post assumes and requires that you have read the introductory post to this series which also includes a table of content. With that out of the way let’s look at some restrictions for some statements, operators and the volatile qualifier.

Following is a list of statements or operators that are not allowed in an amp-restricted function:

  • dynamic_cast;
  • typeid operator
  • goto statements or labeled statements;
  • inline native assembly (asm) declarations;
  • function try blocks, try blocks, catch blocks, or throw;

Also, the volatile type qualifier is not supported in an amp restricted function because the semantics defined by C++ volatile memory cannot be safely emulated by the underlying Direct3D platform. This also means volatile member functions are not supported since a volatile member function actually means the this pointer is volatile, which is not supported.

Comments

  • Anonymous
    January 14, 2012
    Why goto?

  • Anonymous
    January 14, 2012
    Hi Bruno,  I assume your question is why goto is disallowed in restrict(amp). As you may have known, currently, C++ AMP is built on top of DX, whose shader laugnage, HLSL, only supports structured control flow constructs -- goto is not allowed. This is probably due to performance concern or hardware limitations for GPUs. While goto is disallowed,  some other unconditional jump statements, such as break, continue, return, are still allowed. Saying that,  it is possible for C++ AMP compiler to support goto even the target HLSL does not, especially if the goal is to support constrained usage of goto that would not lead to irreducible control flow graph.  So feedback is welcome and we may consider relaxing it in some future release.

  • Anonymous
    January 21, 2012
    Thanks for the reply.  I suspected maybe you just didn't like goto, but HLSL forced your hand. I'll google irreducible control flow now :)