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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
