Assumptions containing CUDA thread and block indices/dimensions get ignored

[OgnianM]

https://godbolt.org/z/az71fMocx

[AaronBallman]

This is not a bug; there are potential side effects there which are being ignored -- that's a pseduo expression which ends up with a function call. The AST dump makes this more obvious:

TranslationUnitDecl
`-FunctionDecl </opt/compiler-explorer/cuda/12.6.1/include/crt/host_defines.h:109:9, line:4:1> line:2:17 square 'void (int *, int)'
  |-ParmVarDecl <col:24, col:29> col:29 array 'int *'
  |-ParmVarDecl <col:36, col:40> col:40 n 'int'
  |-CompoundStmt <col:43, line:4:1>
  | `-AttributedStmt <line:3:5, col:35>
  |   |-CXXAssumeAttr <col:7, col:32>
  |   | `-BinaryOperator <col:14, col:28> 'bool' '<'
  |   |   |-PseudoObjectExpr <col:14, col:24> 'unsigned int'
  |   |   | |-MSPropertyRefExpr <col:14, col:24> '<pseudo-object type>' lvalue
  |   |   | | `-OpaqueValueExpr <col:14> 'const __cuda_builtin_threadIdx_t' lvalue
  |   |   | |   `-DeclRefExpr <col:14> 'const __cuda_builtin_threadIdx_t' lvalue Var 0xecb9ec0 'threadIdx' 'const __cuda_builtin_threadIdx_t'
  |   |   | |-OpaqueValueExpr <col:14> 'const __cuda_builtin_threadIdx_t' lvalue
  |   |   | | `-DeclRefExpr <col:14> 'const __cuda_builtin_threadIdx_t' lvalue Var 0xecb9ec0 'threadIdx' 'const __cuda_builtin_threadIdx_t'
  |   |   | `-CallExpr <col:14, col:24> 'unsigned int'
  |   |   |   `-ImplicitCastExpr <col:14, col:24> 'unsigned int (*)()' <FunctionToPointerDecay>
  |   |   |     `-MemberExpr <col:14, col:24> 'unsigned int ()' lvalue .__fetch_builtin_x 0xecb2bb0
  |   |   |       `-OpaqueValueExpr <col:14> 'const __cuda_builtin_threadIdx_t' lvalue
  |   |   |         `-DeclRefExpr <col:14> 'const __cuda_builtin_threadIdx_t' lvalue Var 0xecb9ec0 'threadIdx' 'const __cuda_builtin_threadIdx_t'
  |   |   `-ImplicitCastExpr <col:28> 'unsigned int' <IntegralCast>
  |   |     `-IntegerLiteral <col:28> 'int' 1024
  |   `-NullStmt <col:35>
  `-CUDAGlobalAttr </opt/compiler-explorer/cuda/12.6.1/include/crt/host_defines.h:231:22>

Closing this issue as not a defect, but if you have further information, feel free to reopen the issue.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Ognyan Mirev (OgnianM)

https://godbolt.org/z/az71fMocx

[Artem-B]

that's a pseduo expression which ends up with a function call.

That's an implementation detail. We do apply known target-specific assumptions about possible range of returned values in LLVM, but that's more conservative than the actual range of values which would be known only to the user.

Is there a way to tell clang that this particular builtin call has no side effects? Right now it's marked as "nc" (nothrow, const).

[AaronBallman]

That's an implementation detail.

Good to know, should we reopen the issue then?

Is there a way to tell clang that this particular builtin call has no side effects? Right now it's marked as "nc" (nothrow, const).

When we get down to the call expression, we look to see whether it's marked pure/const and if it is, we let the children nodes determine whether there are side effects:

llvm-project/clang/lib/AST/Expr.cpp

Line 3662 in 82b4379

bool IsPure = FD && (FD->hasAttr<ConstAttr>() || FD->hasAttr<PureAttr>());

So marking the builtin as const should suffice; you may have to hop into the debugger to find out why we're failing this check:

llvm-project/clang/lib/Sema/SemaChecking.cpp

Line 5268 in 82b4379

if (Arg->HasSideEffects(Context))

[Artem-B]

Let's reopen it. Making assume work for the CUDA builtin "variables" would be useful, and the current diagnostic is misleading.

I will take a look at what's going on there.