Hi, I have a couple of questions about what TARGET_CAN_INLINE_P is alllowed to assume when called from ipa-inline. (Callers from the front-end don't matter for the moment.)
I'm working on an extension where a function F1 without attribute A can't be inlined into a function F2 with attribute A. That part is easy and standard. But it's expected that many functions won't have attribute A, even if they could. So we'd like to detect automatically whether F1's implementation is compatible with attribute A. This is something we can do by scanning the gimple code. However, even if we detect that F1's code is compatible with attribute A, we don't want to add attribute A to F1 itself because (a) it would change F1's ABI and (b) it would restrict the optimisation of any non-inlined copy of F1. So this is a test for inlining only. TARGET_CAN_INLINE_P (F2, F1) can check whether F1's current code is compatible with attribute A. But: (a) Is it safe to assume (going forward) that F1 won't change before it is inlined into F2? Specifically, is it safe to assume that nothing will be inlined into F1 between the call to TARGET_CAN_INLINE_P and the inlining of F1 into F2? (b) For compile-time reasons, I'd like to cache the result in machine_function. The cache would be a three-state: - not tested - compatible with A - incompatible with A The cache would be reset to "not tested" whenever TARGET_CAN_INLINE_P is called with F1 as the *caller* rather than the callee. The idea is to handle cases where something is inlined into F1 after F1 has been inlined into F2. (This would include calls from the main inlining pass, after the early pass has finished.) Is resetting the cache in this way sufficient? Or should we have a new interface for this? Sorry for the long question :) I have something that seems to work, but I'm not sure whether it's misusing the interface. Thanks, Richard