[LLVMdev] LTO, Code Generation Options, etc

[Eric Christopher]

On Mon, Mar 30, 2015 at 9:52 AM Eric Christopher <echristo at gmail.com> wrote:

> 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.
>
> 1) Whether or not to allow changing of target-cpu/target-feature/triple at
> link time code generation.
>
> - 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).
>
> 2) How to pass other sorts of options to the backend for code generation
>
> - -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.
>
> 3) The llvm developer debugging story
>
> - 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.
>

 That said I was actually envisioning something like:

clang -emit-llvm foo.c -o foo.bc
...

clang -O3 -flto all.bc -arch x86_64h -o haswell_slice
clang -O3 -flto all.bc -arch x86_64 -o x86_64_slice

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.

Another usage is the (admittedly one I don't think we want to support)
halide one that I discovered this week:

clang foo.c -emit-llvm foo.bc
clang -target aarch64-linux-gnu foo.bc -O3 -o foo.aarch64
clang -target x86_64-linux-gnu foo.bc -O3 -o foo.x86_64
...

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:

clang -target le64-unknown-unknown -emit-llvm foo.c -o foo.bc
clang -target aarch64-linux-gnu foo.bc -O3 -o foo.aarch64
clang -target x86_64-linux-gnu foo.bc -O3 -o foo.x86_64

Just to add some more actual use cases in the discussion.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150330/873251e5/attachment.html>