[LLVMdev] LTO, Code Generation Options, etc

[JF Bastien]

>
> > 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).
>
> IMO, it's cleanest of the target-cpu/target-feature/etc. are set at
> compile time.  That's where users are accustomed to specifying codegen
> options already, and besides: the frontend needs to know the backend in
> order to conform to the ABI, set macros, emit calls to target-specific
> intrinsics, etc.
>

Cleanest yes, most familiar yes, but doesn't fit the usecase of
PNaCl/Emscripten/Renderscript/Halide/... as Eric was mentioning. These
indeed need to figure out proper ABI, macros, intrinsics, but the existence
of these is a pretty good proof that something can be done (I'm not saying
it's clean or pretty!).


> >  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.
>
> Many of the differences between architectures CPUs affect preprocesser
> definitions, right?  Link-time is too late for the frontend to emit
> Haswell-specific intrinsics, for example.
>
> That said, it would be cool if this worked.
>

Agreed.


> > 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
> > ...
>
> Whereas this is just insane :0.
>

Disagreed: different usecase from above :-)

Whoever maintains "portable" things has to figure out how this works, and I
think right now it's still the wild west (hence insane may not be too far
of a qualification), but I don't think it's an invalid usecase.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150401/645c10dd/attachment.html>