<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Mar 30, 2015 at 9:52 AM Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.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">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><br></div><div>3) The llvm developer debugging story</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></div></blockquote><div><br></div><div>┬áThat said I was actually envisioning something like:</div><div><br></div><div>clang -emit-llvm foo.c -o foo.bc</div><div>...</div><div><br></div><div>clang -O3 -flto all.bc -arch x86_64h -o haswell_slice</div><div>clang -O3 -flto all.bc -arch x86_64 -o x86_64_slice</div><div><br></div><div>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.</div><div><br></div><div>Another usage is the (admittedly one I don't think we want to support) halide one that I discovered this week:</div><div><br></div><div>clang foo.c -emit-llvm foo.bc</div><div>clang -target aarch64-linux-gnu foo.bc -O3 -o foo.aarch64</div><div>clang -target x86_64-linux-gnu foo.bc -O3 -o foo.x86_64</div><div>...</div><div><br></div><div>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:</div><div><br></div><div>clang -target le64-unknown-unknown -emit-llvm foo.c -o foo.bc</div><div>clang -target aarch64-linux-gnu foo.bc -O3 -o foo.aarch64</div><div>clang -target x86_64-linux-gnu foo.bc -O3 -o foo.x86_64</div><div><br></div><div>Just to add some more actual use cases in the discussion.</div><div><br></div><div>-eric</div></div></div>