<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 class="h5">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>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? And while we could add @llvm.stackalignment, would it work to deduce minimum alignment from the alloca statements present?</div><div><br></div><div>Nick</div></div></div></div>