[SCEV]: Teach SCEV about llvm.annotation intrinsic

[etiotto]

Summary

As per the LLVM language reference (https://llvm.org/docs/LangRef.html), the llvm.annotation intrinsic as no effect on code generation and optimization and therefore can be safely replaced by its first argument. This patch 'teaches' SCEV the semantics of that builtin function.

[Meinersbur]

From the language reference:

they are ignored by code generation and optimization.

I agree that this means the annotation can be ignored. But it returning the first argument (as mentioned in the summary) is not sufficient to conclude that, e.g. it could have side effects.

[etiotto]

In D102344#2755915, @Meinersbur wrote:

From the language reference:

they are ignored by code generation and optimization.

I agree that this means the annotation can be ignored. But it returning the first argument (as mentioned in the summary) is not sufficient to conclude that, e.g. it could have side effects.

I can add a test sure, let's first come to a conclusion on the side-effects comment.

It is not clear to me what side-effects the llvm.annotation intrinsic would need to have. The current documentation states that the intrinsic function can be ignored by code gen and optimizations. That means I could move instructions past the intrinsic since the intrinsic can be ignored. If the intrinsics had side effects that optimization would be illegal, and it follows the intrinsic could not be ignored. Do I make any sense?

[Meinersbur]

In D102344#2757705, @etiotto wrote:

It is not clear to me what side-effects the llvm.annotation intrinsic would need to have. The current documentation states that the intrinsic function can be ignored by code gen and optimizations. That means I could move instructions past the intrinsic since the intrinsic can be ignored. If the intrinsics had side effects that optimization would be illegal, and it follows the intrinsic could not be ignored. Do I make any sense?

I am referring to the summary:

The llvm.annotation intrinsic returns the first argument passed to it.

As mentioned, this is not a sufficient condition to be just ignored. The summary should also mention that by the LLVM language reference, " are ignored by code generation and optimization."

Suggestion:

As by the LLVM language reference, the llvm.annotation intrinsic and no effect on code generation and optimization (https://llvm.org/docs/LangRef.html) and therefore can be safely replaced by its first argument. This patch 'teaches' SCEV the semantics of that builtin function.

[etiotto]

I am referring to the summary:

The llvm.annotation intrinsic returns the first argument passed to it.

As mentioned, this is not a sufficient condition to be just ignored. The summary should also mention that by the LLVM language reference, " are ignored by code generation and optimization."

Suggestion:

As by the LLVM language reference, the llvm.annotation intrinsic and no effect on code generation and optimization (https://llvm.org/docs/LangRef.html) and therefore can be safely replaced by its first argument. This patch 'teaches' SCEV the semantics of that builtin function.

Hey Michael, I understand now what you meant. Sure I have updated the description now.

[reames]

Test case?

[shchenz]

I have not noticed this patch, so I posted another patch D127835. Thanks for remind @nikic

Hi @etiotto , there is a small test case in D127835, can we move forward for this patch? I met some issue in SLP vectorizer because of this intrinsic. Thanks.

llvm/lib/Analysis/ScalarEvolution.cpp

if (auto *II = dyn_cast<IntrinsicInst>(U)) {
       }
       case Intrinsic::uadd_sat: {
         const SCEV *X = getSCEV(II->getArgOperand(0));
         const SCEV *Y = getSCEV(II->getArgOperand(1));
         const SCEV *ClampedX = getUMinExpr(X, getNotSCEV(Y));
         return getAddExpr(ClampedX, Y, SCEV::FlagNUW);
       }
       case Intrinsic::start_loop_iterations:
-        // A start_loop_iterations is just equivalent to the first operand for
-        // SCEV purposes.
+      case Intrinsic::annotation:
+        // Equivalent to the first operand for SCEV purposes.
         return getSCEV(II->getArgOperand(0));
       default:
         break;
       }
     }
     break;
   }