<div dir="ltr"><div dir="ltr">On Fri, May 7, 2021 at 4:01 AM via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Looks like GCC manages to use DW_OP_fbreg for the example given, which<br>
> looks like it works/is correct despite the the pushes/pops (because<br>
> it's rbp, I guess - base pointer rather than stack pointer). Perhaps<br>
> we could do something like that too, in cases like this?<br>
<br>
RBP isn't used as a frame pointer in 'example' when building with gcc (7.5.0) or clang<br>
(71597d40e878). It looks like gcc is able to use DW_OP_fbreg because it sets DW_AT_frame_base in the<br>
parent DIE to DW_OP_call_frame_cfa. Is there anything stopping us from doing the same?<br></blockquote><div><br></div><div>That sounds like the right solution. The variable location of a stack object should be based on something that does not change throughout the function.</div><div><br></div><div>LLVM's behavior was probably less of an issue before we started doing call frame optimization for x86 (X86CallFrameOptimization), meaning converting stores to pushes. Before that, LLVM would mostly only emit SP adjustments when a frame pointer was in use, so the variable location would be based on RBP. </div></div></div>