This is an archive of the discontinued LLVM Phabricator instance.

[OpenCL] Do not add builtins with unavailable types
ClosedPublic

Authored by svenvh on Apr 9 2021, 8:38 AM.

Details

Summary

Add functionality to assign extensions to types in OpenCLBuiltins.td and use that information to filter candidates that should not be exposed if a type is not available.

Most of the changes affect the addition of scalar base types into the QT vector in the generated OCL2Qual function (that is, the switch statement as described in step 1 in the OCL2Qual top comment). For types that are associated with an extension, the QualType is now added only if the corresponding extension macro is defined.

The old code was as follows for the FGenTypeN GenericType, which represents all floating point types for all vector sizes.

case OCLT_FGenTypeN:
  QT.append({Context.FloatTy, Context.DoubleTy, Context.HalfTy, Context.FloatTy, Context.DoubleTy, Context.HalfTy, Context.FloatTy, ...
  GenTypeNumTypes = 3;
  GenVectorSizes = ListVecAndScalar;
  break;

With this patch, the generated code becomes:

case OCLT_FGenTypeN: {
  SmallVector<QualType, 3> TypeList;
  TypeList.push_back(Context.FloatTy);
  if (S.getPreprocessor().isMacroDefined("cl_khr_fp64")) {
    TypeList.push_back(Context.DoubleTy);
  }
  if (S.getPreprocessor().isMacroDefined("cl_khr_fp16")) {
    TypeList.push_back(Context.HalfTy);
  }
  GenTypeNumTypes = TypeList.size();
  QT.reserve(18);
  for (unsigned I = 0; I < 6; I++) {
    QT.append(TypeList);
  }
  GenVectorSizes = ListVecAndScalar;
  break;
}

Diff Detail

Event Timeline

svenvh created this revision.Apr 9 2021, 8:38 AM
svenvh requested review of this revision.Apr 9 2021, 8:38 AM
Anastasia added inline comments.Apr 13 2021, 6:42 AM
clang/lib/Sema/OpenCLBuiltins.td
54

I am trying to understand why would we need a special abstraction for the type? Would it not be easier if we just guard the BIFs by the extensions that allow the use of the type?

We would need to separate the definitions of course but this can be more helpful in order to understand what overloads are available conditionally?

svenvh added inline comments.Apr 13 2021, 7:21 AM
clang/lib/Sema/OpenCLBuiltins.td
54

Yes, it is possible to achieve the same with the current FunctionExtension class.

However, that would require a lot of duplication in the Builtin descriptions, as for example many math builtins have overloads for half and double that will have to be conditionalized. The purpose of TypeExtension is precisely to avoid separating and duplicating the definitions. For example, acos is currently more or less defined as:

def FGenTypeN : GenericType<"FGenTypeN", TypeList<[Float, Double, Half]>, VecAndScalar>;
def : Builtin<"acos", [FGenTypeN, FGenTypeN], Attr.Const>;

with double and half conditionalization conveniently handled in a single place through a TypeExtension.

If we would only use FunctionExtensions, the definition would become more like the following:

def FGenTypeN : GenericType<"FGenTypeN", TypeList<[Float]>, VecAndScalar>;
def : Builtin<"acos", [FGenTypeN, FGenTypeN], Attr.Const>;

let Extension = Fp64 in {
  def DGenTypeN : GenericType<"DGenTypeN", TypeList<[Double]>, VecAndScalar>;
  def : Builtin<"acos", [DGenTypeN, DGenTypeN], Attr.Const>;
}

let Extension = Fp16 in {
  def HGenTypeN : GenericType<"HGenTypeN", TypeList<[Half]>, VecAndScalar>;
  def : Builtin<"acos", [HGenTypeN, HGenTypeN], Attr.Const>;
}

I personally don't think there is value in adding these explicit guards for every conditional builtin, as the duplication makes the definitions harder to maintain. In addition, I expect it would also increase the size of the generated tables, as the GenericTypes have to be split up (though I have not measured this).

Anastasia added inline comments.Apr 13 2021, 8:44 AM
clang/lib/Sema/OpenCLBuiltins.td
54

Ok I see. Yeah it looks quite a lot of duplication indeed for some types. However, this patch provides extra flexibility and doesn't enforce to use the new approach evrywhere so I think it is very reasonable.

Could you just provide a bit more documentation and especially the difference to the other approach here?

Do you think it is work extending the online documentation for that too?

clang/lib/Sema/SemaLookup.cpp
762

This deserved the comment.

svenvh updated this revision to Diff 337663.Apr 15 2021, 1:43 AM

Adding some more comments / explanation.

svenvh added inline comments.Apr 15 2021, 1:50 AM
clang/lib/Sema/OpenCLBuiltins.td
54

Do you think it is work extending the online documentation for that too?

Yes we should, but it is perhaps worth waiting until we have clarified the design wrt feature optionality.

Anastasia accepted this revision.Apr 15 2021, 5:56 AM

LGTM! Thanks!

This revision is now accepted and ready to land.Apr 15 2021, 5:56 AM
This revision was landed with ongoing or failed builds.Apr 21 2021, 4:00 AM
This revision was automatically updated to reflect the committed changes.