<div dir="ltr"><br><br><div class="gmail_quote">On Tue, Mar 31, 2015 at 8:59 PM Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On 2015 Mar 30, at 10:11, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Mar 30, 2015 at 9:52 AM Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br>
> 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.<br>
><br>
> 1) Whether or not to allow changing of target-cpu/target-feature/<u></u>triple at link time code generation.<br>
><br>
> - 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).<br>
<br>
IMO, it's cleanest of the target-cpu/target-feature/etc. are set at<br>
compile time.  That's where users are accustomed to specifying codegen<br>
options already, and besides: the frontend needs to know the backend in<br>
order to conform to the ABI, set macros, emit calls to target-specific<br>
intrinsics, etc.<br>
<br>
I'll send a review of r233227 in a moment to that effect ;).<br>
<br>
> 2) How to pass other sorts of options to the backend for code generation<br>
><br>
> - -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.<br>
<br>
This is easy to solve for -fno-inline in particular: we should just<br>
add a function attribute (`noinline`?) that the inliner should treat<br>
as a synonym for `optnone`.  Any functions that come from translation<br>
units compiled with `-fno-inline` get ignored by the inliner; functions<br>
from other translation units participate fully.<br>
<br></blockquote><div><br></div><div>This is pretty terrible as you allude to here, this is a hack for -fno-inline, but it's also not good for "I'd like to inline at the individual translation unit compile time, but not at the LTO time."</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But in terms of setting up the LTO pass pipeline, some level of user<br>
customization makes sense.  I'm not really sure how much is useful.  We<br>
have a start at that with Peter's recent commits to add -O0/-O1/-O2<br>
(not that anyone thought too carefully about what's happening at those<br>
optimization levels).<br></blockquote><div><br></div><div>Yeah, I commented pretty heavily on that thread if you'll remember. It's a hackish workaround for the moment, but will work in the short term.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 3) The llvm developer debugging story<br>
><br>
> - 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.<br>
<br>
I think some sort of rewriter makes sense.<br>
<br>
Long-term I'd still like to encode whether an option is overridable in<br>
a sane way (via a default attribute sets or something), but I haven't<br>
had time yet to go back to my original proposal and refine it :(.<br>
<br></blockquote><div><br></div><div>If I had any bright ideas I'd have said something. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
>  That said I was actually envisioning something like:<br>
><br>
> clang -emit-llvm foo.c -o foo.bc<br>
> ...<br>
><br>
> clang -O3 -flto all.bc -arch x86_64h -o haswell_slice<br>
> clang -O3 -flto all.bc -arch x86_64 -o x86_64_slice<br>
><br>
> for the same set of bitcode files. But given the front end language restrictions on doing anything actually interesting there it's not too much of a constraint.<br>
<br>
Many of the differences between architectures CPUs affect preprocesser<br>
definitions, right?  Link-time is too late for the frontend to emit<br>
Haswell-specific intrinsics, for example.<br>
<br></blockquote><div><br></div><div>*nod* But useful for making code generation decisions (vectorization etc).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That said, it would be cool if this worked.<br>
<br></blockquote><div><br></div><div>Yep, which leads us to:</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Another usage is the (admittedly one I don't think we want to support) halide one that I discovered this week:<br>
><br>
> clang foo.c -emit-llvm foo.bc<br>
> clang -target aarch64-linux-gnu foo.bc -O3 -o foo.aarch64<br>
> clang -target x86_64-linux-gnu foo.bc -O3 -o foo.x86_64<br>
> ...<br>
<br>
Whereas this is just insane :0.<br></blockquote><div><br></div><div>Sorta...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
> I've since convinced them to use the pnacl sort of thing for more target independent code generation at the moment. It's a use case that could be thought about more though - especially as pnacl does the exact same sort of thing, just with a different triple for actual link time code generation, it looks more like:<br>
><br>
> clang -target le64-unknown-unknown -emit-llvm foo.c -o foo.bc<br>
> clang -target aarch64-linux-gnu foo.bc -O3 -o foo.aarch64<br>
> clang -target x86_64-linux-gnu foo.bc -O3 -o foo.x86_64<br></blockquote><div><br></div><div>This is probably a bit more sane, i.e. a generic situation. PNaCl has been using this exact use case for quite a while now and, IIUC it's also the basis of the new Khronos proposal. It'd be nice to support this sort of thing in some fashion (i.e. make restrictions), but I think at this point telling them their behavior isn't allowed would be a little mean :)</div><div><br></div><div>-eric</div></div></div>