<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 30, 2015 at 9:52 AM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.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">From PR18808 I said a few things and that I was going to redirect to the mailing list for further discussion. So here we are, go.<div><br></div><div><div>1) Whether or not to allow changing of target-cpu/target-feature/triple at link time code generation.</div><div><br></div><div>- Not convinced here of the facility to do so. Could just recompile the individual bitcode files to get what you want, but there are some users that are trying to ship bitcode (as crazy as that sounds).</div><div><br></div><div>2) How to pass other sorts of options to the backend for code generation</div><div><br></div><div>- -ffoo options -fno-foo options. I.e. -fno-inline, etc. I think this is really pretty important from the user POV. It affects things at a more global level.</div></div></div></blockquote><div><br>I assume many of these still could/should be function-specific attributes, no? (it seems like there's a logical interpretation of compiling one object file with -fno-inline and another without it - the same as having __attribute__((noinline)) on the functions of the first object and not on those of the second - this may not apply to other options, but perhaps there's a better example of options we should think about here that don't have a per-function interpretation?)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>3) The llvm developer debugging story<br></div></div></div></blockquote><div><br>Was this the thing Duncan was talking about/proposing on llvmdev a few weeks ago? Something about command line overridable options, etc? (I can try to find the thread if that doesn't sound familiar)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div></div><div><br></div><div>- It's useful for llvm developers to be able to more accurately debug a set of IR using bisection or being able to turn off code generation options. Should this be done at the command level (i.e. infrastructure that clang and llc etc could even share), or should it be done at an llvm IR rewriting level? Don't know. I kind of want a rewriter, but I'm not wedded to any particular answer.</div></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-eric</div><div><br></div><div><br></div></font></span></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div>