[PATCH] Correctly handle truncates when detecting tail-call opportunities in the presence of the 'returned' attribute

[Stephen Lin]

Hi,

This patch resolves an issue noticed by Tim Northover off-list: the
function sameNoopInput in lib/CodeGen/Analysis is treating the return
value of the caller and the callee symmetrically allowing either to be
truncated (if the target reports that this truncation is a no-op),
which is leading to a tail call opportunity incorrectly being detected
on X86-64 in the following example:

    declare i32 @ret32(i32 returned)

    define i64 @test1(i64 %val) {
     %in = trunc i64 %val to i32
     tail call i32 @ret32(i32 returned %in)
     ret i64 %val
    }

This is not valid because the call to "@ret32 is not guaranteed to
preserve the full 64bit value. On the other hand, tail calls are valid
in the following two examples:

    declare i32 @ret32(i32 returned)
    declare i64 @ret64(i64 returned)

    define i32 @test2(i64 %val) {
     %in = trunc i64 %val to i32
     tail call i64 @ret64(i64 returned %val)
     ret i32 %in
    }

    define i32 @test3(i64 %in) {
     %small = trunc i64 %in to i32
     tail call i32 @ret32(i32 returned %small)
     ret i32 %small
    }

Tim is working on a larger patch that addresses this bug and also
generalizes tail call detection in other ways. However, I think it
makes sense to patch this issue separately first with a targeted bug
fix, so if any problem requires the larger patch to be reverted
temporarily we will have a working baseline version to return to.
(Definitely, Tim's in-progress patch which generalizes this logic is a
good idea, so that should be applied regardless once it's complete.)

Please let me know if you have any feedback or comments.

Stephen

<rdar://problem/14519392>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-returned-tail-calls-bugfix-only.patch
Type: application/octet-stream
Size: 5694 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130724/41ccb1ef/attachment.obj>