[PATCH] D21698: [OpenCL] Allow disabling types and declarations associated with extensions

[Anastasia Stulova via cfe-commits]

Anastasia added a comment.

I have made an experiment with a simple kernel:

  void foo1(void);
  void foo2(void);
  void foo3(void);
  void foo4(void);
  void foo5(void);
  void foo6(void);
  void foo7(void);
  void foo8(void);
  void foo9(void);
  void foo10(void);
  
  void test(){
    foo1();
    foo2();
    foo3();
    foo4();
    foo5();
    foo6();
    foo7();
    foo8();
    foo9();
    foo10();
  }

I am using time utility of linux to measure the compile time running Clang in CL2.0 mode and average over 100 samples. It shows me around 7% overhead with your approach.

Even thought it doesn't seem to be large overhead in this test, however it would be undesirable to have any regressions in compilation time in the future Clang releases for OpenCL basic functionality. Our target should be constantly to improve on that unless we have a good reason not to. But in this case I don't feel like the reason is strong enough. Also it would be nice to study more use cases to see how the compilation time scales. Compilation time might be a concern for runtime compilations especially in embedded/constraint platform.

Based on this, one alternative I would like to propose - how about we use old mechanism for standard OpenCL extensions that come from the Spec and dynamic maps for vendor extensions? We can then have an early return to avoid the expensive checks if  the maps of extensions are empty (OpenCLTypeExtMap, OpenCLDeclExtMap) or full check if they contain any elements. In this case if vendors are fine with having slight overhead of compilation time they can use the feature to add their extensions flexibly, otherwise they will have to stay with an old approach of extending Clang directly. What do you think about it? Any other proposals are welcome too!


https://reviews.llvm.org/D21698