<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/57444>57444</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            Incorrect call-site-info for argument locations
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          jmorse
      </td>
    </tr>
</table>

<pre>
    Here's some code that deliberately switches between translation units -- if you compile both together with 07bfbce98872398ab58a4931ee88ccd2749a1ada and `clang test.c test2.c -o a.out -g -O2  -gdwarf-4`, then I get what looks like an incorrect call site variable location in the "foo" function. It doesn't present in a debugger due to being a tail call, and I can't immediately get a reproducer that does present in a debugger, but I think this is indicative of something being broken. The code:

test.c:

    #include <stdio.h>

    int bar(int, int);
    int baz();
    int foo(long a, long b) {
      baz();
      return bar(a, b);
    }

    int qux() {
      printf("ohai\n");
      return 0;
    }

test2.c:

    int foo(long, long);
    int qux();
    int main() {
      return foo(1, 2);
    }

    int bar(int a, int b) {
      qux();
      return 0;
    }

    int baz() {
      return 0;
    }

Deliberately tries to set up call-site-info for calling into `bar` from `foo`. The disassembly for foo:

    <foo>:
        push   %r14
        push   %rbx             
        push   %rax             
        mov    %rsi,%r14        
        mov    %rdi,%rbx        
        xor    %eax,%eax        
        callq  670 <baz>
        mov    %ebx,%edi        
        mov    %r14d,%esi       
        add    $0x8,%rsp
        pop    %rbx             
        pop    %r14
        jmpq   660 <bar>

The call site info:

    DW_TAG_GNU_call_site
      DW_AT_abstract_origin (0x000000bc "bar")
      DW_AT_GNU_tail_call   (true)
      DW_AT_low_pc  (0x0000000000000622)

        DW_TAG_GNU_call_site_parameter
          DW_AT_location      (DW_OP_reg4 RSI)
          DW_AT_GNU_call_site_value   (DW_OP_breg14 R14+0)

       DW_TAG_GNU_call_site_parameter
         DW_AT_location      (DW_OP_reg5 RDI)
         DW_AT_GNU_call_site_value   (DW_OP_breg3 RBX+0)

The call site info has found that the argument values originate from r14 and rbx, however it's missed the fact that they're clobbered in the intervening few instructions, by the final two pops for the tail call. Were this to not be a tail call, we would then risk the contents of an uncontrolled register being presented as the argument value in the callee. I think this problem is probably limited to scenarios where the value goes out of liveness in the same block as the call that uses the value, and the register is immediately repurposed for something else. This is hard to hit from small test cases, but probably does happen in large code bases.

I'm not especially familiar with how the call site information moves around, but I would imagine that some kind of analysis like machine-sink is needed, i.e. examining whether aliases of the variables register are def'd or not. (CC @djtodoro ). I think I speculated this in the past somewhere, but IMHO this is the kind of area that instruction referencing's exact knowledge of value locations could be useful and complimentary -- it would be straightforwards to search for backup locations for the value, including stack spills slots, once LiveDebugValues runs. (LiveDebugValues doesn't analyse "real" stack variables though, i.e. ones that weren't fully promoted).
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJyVV1tz4jYU_jXwooExxsHwwMMm2Utm2m4n3Xb7xsi2jBVky5XkkPTX9zuSMYSQ7NaTYLCOz-U7F33KdPG8_iKMGMWpZVbXguW6EMxV3LFCKJkJw51Qz8zupcsrYVkm3F6IhjnDG6u4k7phXSOdZZMJkyV71h101K1UgmXaVczprXCVMAwaKhalWZnlYrVcpvF8teTZ1ZInq_lMiOUyz4s4TVZ8xgvOeFOw0SLKFW-2zAnrprm_xbhPNONT3Tk22bLJ15jhXuy5KScJ3hjFN_AfHt4xGGZ7CkVpvbNMyZ2AXiabXBsjcsdyrhSz0gn2yI3kGXxWOg9ByYbUsFEcl1rjk5Vdk9PKlN0BHC1sA9Qca42wonEkz4FZ1m23CLbogKIGWhLuc-a4VN4aeUeh3eFXeF_WtShkQJkc5syI1uiiy6EmJAK2LpshbRlwuIOgbHb0aRn9NYWkMB4F06XPK61ve3cyo3cCYXyrQrpH8w-j6HYU9Z8B7LOHDNcongM61aFARvMb6wqpp9Vo_vFcTsLNjMO5Jb6Ri_62Gs2vz2X-hcylFY_4UmnCjhT4bxkk2Sg9EWVvqGCA0HWm6b3wKrJzoVF6e8nxf7qnoPHcVGuwXPq1WFdcjq5ukMD4TdvRe9b6Sr4A8svwD8FfAmnw9NVKzWVzOYjet2BgRtpfBfAGLkNCQ0b8owsGLjv1c6C8qos3vH9Xye3p1HJGonXQhxaN1bW-AyfU7xPZlBowGP-ImgKGNQ0cinMRsdLomn4SUoso9EohLbdW1Bk006u0dqFL5jd-4eOwxvqr7Wzl2-jKzJI3l7Indnq9Kcffk6v1I-vlrES-gs0fyhYH2aMTL2WfEHaQFfwpyAr-hiwh-w9jizQiTCiph1Hx2rLIDtoK-UMvZ0nRC1t5UZYXRZBNoqdlH5Ftz5DU7UHf-4gf5c6T9lC3iI8tFn2A5mwW-vk67DBUcRfK5fb75tuHz5vPv_25IdkNyZ6awfqHbxueWWy4udtoI7fYAtAf0VPkryynPcq3p-_lV--Satp_vH4fytKZTlyUVXq_aXN2qr-_FifaX8JwKYJNyw3HroMt6oXs0U6_ywbE4yUef_19Y8Q2Yfd_3J359jKWo5FHrrDNnryfQQHK_B6Ziq-jy_7-L3d_5O0Vu7-94O1POztn99d_X_D1demwiltMnA7cwZMC4ibcbLuaSIHXbVkoDoy-ML6o44lrGN9crNJ78QhOIZ1ne7XELCu8nhKVNWh9xqqBdaUzzFFI9EQIA1KYR9HQsCzFHr9Rkp1nRNZvsM9BFxxQzO01dY71c5IeDwRoyr5Da2AqmLiNxrwX5wxpL9hed6oIRM5Iu_NKcg0fGlBNkBpOtJMeGK0UvASY0sLDnuP0dAkLgO01VoegyKAQ05cECuwLTLBm_VdO817JWpI22kty0YAtagtuGUIRvdItETXipfBPgXw1wtqDJYv6YhkqaXfwyOfXo95ZYY9qDhSRHgxREak7IYqgiJ1pNSWQED4yPKGsoN0q8MCKG-9yJV0oCVt7o2AfMA-rBwI5xOm5ZsXbVngGrABbfybISH56WqQo_LT2GRS2FbmEamyMvJZK8p7uo-aOsQ61bOrQTpjpsMYNVfWRyobMy5qjlvujiD-Z7MBqQ-a5eray5_M1zxG4wK6O9OFhI0QhvDY5BRLiCf74mkWy_DGEwzvCG5oC5IH42yPWHEktBKheCnuGApxS197csFESFQ9OF9qAK8SrY93cMUKgw3nIt5Qc0t5yG9z3tTIE-euXrwNZJ7EhNiN4CPmkveBZiZebXBIRROsiKDTsrtF7VP7Wc_xQgIdBZZEyAhGdhdoqO-ULio5lqGM0ATfP_rjmerAhR_uL3FYO2cFRquhZEzd55Sss4_kOBOpo4NDYQ8mGowEhbR2EAYhUCodKpZ0vM93kgv2Crrilw8tfYWKZrrEe3POF4_kqpNsfxACOopNYMHDMnKt0t62GnOvGPwOIe4LNawEGKE6Uea0dlcdqOhbr2WIxWy6S1TIZF-t5sZqv-NhJp8T67sUR8YwyDqNkQGPcGbWunGst7fDxJ_xtUf5dNgXm-KHU4-E2gQ8PUIyfGMAdteCnqzRJknG1vsrKOE_KNBeZWK3KeZrif5bmC55yXixXY8UzNPh6dHUNGBoawqSCNv6r27Fcx1EcR8t5NJtHqySZrpIYby-LWZnO50mRonoFjgZqSn5MtdmOzdq7BNgtFhXK3x4XwXXlFu3kzUE_74CzWT_U2lgx9pbX3vP_ACTe_Sk">