Not only the function declaration can have the minsize attribute set, but also the call site. I don't think we would like to specialise when a call instruction has minsize set.
Details
Diff Detail
Unit Tests
Time | Test | |
---|---|---|
560 ms | x64 debian > libomp.lock::omp_init_lock.c |
Event Timeline
llvm/lib/Transforms/IPO/FunctionSpecialization.cpp | ||
---|---|---|
662 | If I understand correctly this should only disallow specialization of this callsite as opposed to the function if any callsite is marked minsize. This is aligned with the intent of minsize applied at the callsite. Do we need to add a similar check to rewriteCallSites? | |
672–673 | nit: Prefer submitting this unrelated style change as an NFC. |
llvm/lib/Transforms/IPO/FunctionSpecialization.cpp | ||
---|---|---|
662 | It is an interesting question that if the attribute marked on callsite should be applied to callee function. Since it is possible that there is an attribute in callsite only. So here is the decision point:
Another funny question is that if the attribute marked on callsite should be applied to callee function. How should we consider indirect call. I mean, once we found an indirect call with specific attribute, should we do alias analysis to check how many functions should this indirect call could be? |
llvm/lib/Transforms/IPO/FunctionSpecialization.cpp | ||
---|---|---|
662 | Yeah, I also found this an interesting case and I wasn't entirely sure about what the behaviour should be. In general, I think we have 3 combinations:
But looking and thinking about this case, when minsize is only set for the callsite, we would still specialise functions. I think I would find that result surprising as we would increase code-size despite the minsize attribute on the call instruction. So, with this patch, we don't specialise when minsize is when one of the callsite or callee has minsize, or both (and now we capture all 3 cases). What do you think about this? | |
672–673 | Sure, will remove it from here. |
llvm/lib/Transforms/IPO/FunctionSpecialization.cpp | ||
---|---|---|
662 | IMO, the behavior in this patch looks OK to me. I think there 2 cases:
In other words, the attribute in callstie only marks the attribute in the callsite only. It wouldn't and shouldn't affect if other transformation outside of the callsite. | |
696 | If we decide not to add a check in the end, we need to add comment to clarify it. |
I have left a comment in rewriteCallSites, and added an extra test function-specialization-minsize3.ll that contains 2 calls with only one of them annotated with MinSize to make it even clearer that we only rewrite the callsites that don't have minsize set.
LGTM with the comments addressed.
llvm/lib/Transforms/IPO/FunctionSpecialization.cpp | ||
---|---|---|
663 | We need to mark AllConstant as false before we continue. Otherwise it is possible that the original function may be considered as unreachable incorrectly. |
llvm/lib/Transforms/IPO/FunctionSpecialization.cpp | ||
---|---|---|
663 | Will add that before committing. Thanks both for reviewing. |
If I understand correctly this should only disallow specialization of this callsite as opposed to the function if any callsite is marked minsize. This is aligned with the intent of minsize applied at the callsite. Do we need to add a similar check to rewriteCallSites?