Currently we don't have a good way of generating the required files for native call inlining.
Created attachment 235973 [details] Patch
Comment on attachment 235973 [details] Patch Can you please add a comment in the ChangeLog to indicate why this fix is needed? For example, say something about the feature of inlining native functions id dependent on features of the Clang compiler.
Maybe we should create a feature flag for the native inlining stuff? That might be a little clearer than just slapping COMPILER(CLANG) in a bunch of places.
(In reply to comment #3) > Maybe we should create a feature flag for the native inlining stuff? That might be a little clearer than just slapping COMPILER(CLANG) in a bunch of places. Yes, I agree. That is a better plan.
Created attachment 236097 [details] Patch
Comment on attachment 236097 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=236097&action=review Also please rebase to ToT so that it’ll be easier to review this in context. Thanks. > Source/WTF/wtf/Platform.h:740 > +#if PLATFORM(EFL) > +#define ENABLE_FTL_NATIVE_CALL_INLINING 0 > +#else > +#define ENABLE_FTL_NATIVE_CALL_INLINING 1 > +#endif // PLATFORM(EFL) Please change this to be dependent on COMPILER(CLANG) instead of PLATFORM(EFL) since that is the true nature of the dependency. You could disable it for !COMPILER(CLANG) || PLATFORM(EFL) if you also don’t want to use it for EFL regardless of the compiler.
Created attachment 236103 [details] Patch
Created attachment 236104 [details] Patch Fixed a typo
Comment on attachment 236104 [details] Patch r=me
Comment on attachment 236104 [details] Patch Clearing flags on attachment: 236104 Committed r172149: <http://trac.webkit.org/changeset/172149>
All reviewed patches have been landed. Closing bug.