Adding NonNull as attributes to returned pointers has the unfortunate side effect of disabling tail calls. This
ignores the NonNull attribute, in the same way that we ignore the NoAlias attribute as it has no affect on the
calling convention.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/CodeGen/CodeGenPrepare.cpp | ||
---|---|---|
1876 ↗ | (On Diff #165987) | I don't follow why you're deleting this code. |
lib/CodeGen/CodeGenPrepare.cpp | ||
---|---|---|
1876 ↗ | (On Diff #165987) | Oh right, I meant to put a comment about that. From what I can tell it appears to be testing CalleeAttrs against itself, and this check should be handled by the calls to attributesPermitTailCall above. Unless I'm missing what this is testing? |
lib/CodeGen/CodeGenPrepare.cpp | ||
---|---|---|
1876 ↗ | (On Diff #165987) | Oh, yes, I see. This isn't doing anything. Please make sure we have appropriate test coverage (maybe in test/CodeGen/X86/tailcall-cgp-dup.ll). |
lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
63 ↗ | (On Diff #165987) | Test coverage for this change? (This codepath is primarily used by SelectionDAGLegalize::ExpandLibCall, so probably unlikely to be relevant in practice, but it should be possible to construct a synthetic testcase.) |
lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
63 ↗ | (On Diff #165987) | My understanding is that we need an intrinsic that returns a ptr and is lowered to a call. Any idea what that might be? I had a look round and couldn't find anything, and an assert that RetTy isn't a pointer type didn't throw up anything in the test suite. |
lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
63 ↗ | (On Diff #165987) | You don't actually need an intrinsic that returns pointer; you can just take an intrinsic that returns an int and use inttoptr on the result. |
lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
63 ↗ | (On Diff #165987) | The check in ExpandLibcall seems to be: bool isTailCall = TLI.isInTailCallPosition(DAG, Node, TCChain) && (RetTy == F.getReturnType() || F.getReturnType()->isVoidTy()); If I comment out that return type check, it does seem to tail call something like __clzsi2 as expected (and nonnull used to disable this, no longer does). But as-is, doesn't seem to like tail calling if the types don't match up. |