Hi Nick,<div><br></div><div>Thanks for your suggestions! Please find some replies and more questions below.<br><div><br></div><div><div class="gmail_quote">On Wed Nov 19 2014 at 2:40:29 AM Nick Lewycky <<a href="mailto:nlewycky@google.com">nlewycky@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 17 November 2014 11:28, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+nlewycky<div><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, Nov 17, 2014 at 9:36 AM, Volodymyr Kuznetsov <span dir="ltr"><<a href="mailto:vova.kuznetsov@epfl.ch" target="_blank">vova.kuznetsov@epfl.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Kostya,<span><br><br>
On Sat, Nov 15, 2014 at 1:53 PM, Volodymyr Kuznetsov <<a href="mailto:vova.kuznetsov@epfl.ch" target="_blank">vova.kuznetsov@epfl.ch</a>> wrote:<br>
> Do you think moving the pass to lib/Transform/Instrumentation but<br>
> scheduling it during code generation would make sense ? If so, we'll<br>
> do that and change the safestack tests to use opt instead of llc.<br>
<br></span>I tried to move the SafeStack to lib/Transform/Instrumentation, but I realized that the SafeStack pass depends on TargetMachine: it gets the stack alignment from TargetFrameLowering and the location of the unsafe stack pointer from TargetLowering. It seems that making TargetMachine available in opt would require opt to depend on more things from CodeGen than it normally should.<br></blockquote><div><br></div></div></div><div>Nick, please comment on TargetMachine in LLVM. </div><div>Can we get stack alignment and current stack pointer at the LLVM level, before CodeGen (i.e. so that it works in opt, not in llc)</div></div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I haven't read the paper or patch yet, but reading the thread it does sound like we should put it into an IR pass if possible. We'll have the flexibility to schedule when it runs; I agree in the LTO case it's important not to run it until right before codegenprepare, but we can sort that out later (we want the pass pipeline for compiles in LTO builds to be different from the pipeline for regular compiles producing object files, but it isn't yet).</div><div><br></div><div>There is some access to TargetMachine from the IR passes, but instead of extending that, could we add new intrinsics? There already is @llvm.returnaddress and @llvm.frameaddress. Do you want @llvm.stackaddress? or would @llvm.frameaddress suffice?</div></div></div></div></blockquote><div><br></div><div><div>The SafeStack pass essentially picks some of the alloca instructions and replaces them with allocations on the unsafe stack. Since the unsafe stack frames are simpler then regular stack frames (e.g., they don't contain any register spills) and LLVM doesn't know about the unsafe stack anyway, the SafeStack pass is itself responsible for computing the layout of the unsafe stack frames. This computation is pretty low-level and needs the concrete value of the unsafe stack alignment, the intrinsic wouldn't suffice for this purpose.<br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>And while we could add @llvm.stackalignment, would it work to deduce minimum alignment from the alloca statements present?</div></div></div></div></blockquote><div><br></div><div>The stack alignment must be enforced inter-procedurally: each function expects it to be at least given predefined function. Hence, analyzing local alloca instruction won't be enough.</div><div><br></div><div>In principle, we could just make the alignment to be some constant large value across all platforms, but that would impact performance. Getting the actual stack alignment for the current platform makes much more sense.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">There already is @llvm.returnaddress and @llvm.frameaddress. Do you want @llvm.stackaddress? or would @llvm.frameaddress suffice?<br></div></div></div></blockquote><div><br></div><div>The unsafe stack uses it's own stack pointer, which is stored either in a thread-local variable or in the thread control block data structure. This is very platform dependent, so we added a function to TargetLowering which determines this location for each platform, based on TargetMachine (similarly to the existing getStackCookieLocation function, which is used for analogous purpose by the existing StackProtector pass). Should we just create the TargetMachine instance in opt (similarly to how it is created during link-time optimizations) ?</div></div><div><br></div><div>Thanks!</div><div>- Vova<br></div></div></div></div>