[clang][BPF] Update comment to include TYPE_MATCH

[d-e-s-o]

Summary

D126838 added support for the TYPE_MATCH compile-once run-everywhere
relocation to LLVM proper. On the clang side no changes are necessary,
other than the adjustment of a comment to mention this relocation as well.
This change takes care of that.

[yonghong-song]

LGTM. But add the reference (https://reviews.llvm.org/D126838) to the commit message to indicate which 'earlier change'. Also let us merge it unti kernel side change is in reasonable shape.

[d-e-s-o]

In D126839#3554125, @yonghong-song wrote:

LGTM. But add the reference (https://reviews.llvm.org/D126838) to the commit message to indicate which 'earlier change'. Also let us merge it unti kernel side change is in reasonable shape.

Adjusted the description. Thanks for the review.

[d-e-s-o]

In D126839#3554125, @yonghong-song wrote:

Also let us merge it unti kernel side change is in reasonable shape.

From what I understand it may take several days or some other not-precisely specified time until "nightly" builds, which we use in the BPF CI, pick up the change. Hence, I was under the impression that we should attempt to merge it sooner rather than later once it's ready to be merged. The kernel changes are in good enough shape to show feasibility, so I don't really see why not, but it's your call.

[yonghong-song]

In D126839#3554474, @d-e-s-o wrote:

In D126839#3554125, @yonghong-song wrote:

Also let us merge it unti kernel side change is in reasonable shape.

From what I understand it may take several days or some other not-precisely specified time until "nightly" builds, which we use in the BPF CI, pick up the change. Hence, I was under the impression that we should attempt to merge it sooner rather than later once it's ready to be merged. The kernel changes are in good enough shape to show feasibility, so I don't really see why not, but it's your call.

We can merge after the new mechanism is acked (not patch getting merged) in kernel review.

[d-e-s-o]

In D126839#3554474, @d-e-s-o wrote:

In D126839#3554125, @yonghong-song wrote:

Also let us merge it unti kernel side change is in reasonable shape.

From what I understand it may take several days or some other not-precisely specified time until "nightly" builds, which we use in the BPF CI, pick up the change. Hence, I was under the impression that we should attempt to merge it sooner rather than later once it's ready to be merged. The kernel changes are in good enough shape to show feasibility, so I don't really see why not, but it's your call.

I just discussed that with Andrii. He is also of the opinion that we should wait until the kernel changes are published. Forget about my comment and let's do that then.

[d-e-s-o]

In D126839#3554570, @yonghong-song wrote:

In D126839#3554474, @d-e-s-o wrote:

In D126839#3554125, @yonghong-song wrote:

Also let us merge it unti kernel side change is in reasonable shape.

From what I understand it may take several days or some other not-precisely specified time until "nightly" builds, which we use in the BPF CI, pick up the change. Hence, I was under the impression that we should attempt to merge it sooner rather than later once it's ready to be merged. The kernel changes are in good enough shape to show feasibility, so I don't really see why not, but it's your call.

We can merge after the new mechanism is acked (not patch getting merged) in kernel review.

Sounds good.

clang/lib/Sema/SemaChecking.cpp

static bool isEltOfVectorTy(ASTContext &Context, CallExpr *Call, Sema &S,
   return true;
 }
 
 static bool isValidBPFPreserveTypeInfoArg(Expr *Arg) {
   QualType ArgType = Arg->getType();
   if (ArgType->getAsPlaceholderType())
     return false;
 
-  // for TYPE_EXISTENCE/TYPE_SIZEOF reloc type
+  // for TYPE_EXISTENCE/TYPE_MATCH/TYPE_SIZEOF reloc type
   // format:
   //   1. __builtin_preserve_type_info(*(<type> *)0, flag);
   //   2. <type> var;
   //      __builtin_preserve_type_info(var, flag);
   if (!isa<DeclRefExpr>(Arg->IgnoreParens()) &&
       !isa<UnaryOperator>(Arg->IgnoreParens()))
     return false;