Part of PR39119
Diff Detail
- Repository
- rL LLVM
Event Timeline
@efriedma, Is this acceptable or not? In the future, the instruction sinking would be moved out of instcombine, but the call inst sinking problem needs to be solved anyway. I don't think we should disable call inst sinking totally.
I see that there were some perf numbers in https://bugs.llvm.org/show_bug.cgi?id=39119#c11,
but those are global, not for this patch. Anything for this change specifically?
test/Transforms/InstCombine/no-sink-nonnull-args.ll | ||
---|---|---|
2 | Please precommit the test. It isn't obvious what the diff changes here. |
I will precommit them if folks say this is fine direction to go.
If we sink the call instructions, Florian's new SCCP patches related to null checks optimizations are unable to benefit from the dominating call with nonnull args.
Florian disabled sinking to see the potential of his new SCCP optimizations, but we need a stronger solution (to not regress in other areas).
If no existing test is affected by this, you most likely want the tests anyway.
If we sink the call instructions, Florian's new SCCP patches related to null checks optimizations are unable to benefit from the dominating call with nonnull args.
Florian disabled sinking to see the potential of his new SCCP optimizations, but we need a stronger solution (to not regress in other areas).
Ok, the problem I have is not related with sinking. Closing this revision.
I want to mark call sites of C functions with nonnull attr. like "strlen (nonnull s)". But since EnableNonnullArgPropagation is disabled, the attrs are not promoted to parent function arguments. And that's the reason why my motivating example from PR39119 with strcmp is not optimized :(
I still think if we safely mark call sites (or unmark attrs of function if we don't know exact size; for C functions with size arg), enabling "NonnullArgPropagation" should not harm. Eli?
Please precommit the test. It isn't obvious what the diff changes here.
No existing tests change?