[LLVMdev] LTO, Code Generation Options, etc

[Eric Christopher]

On Wed, Apr 1, 2015 at 8:07 PM Duncan P. N. Exon Smith <dexonsmith at apple.com>
wrote:

>
> > On 2015 Apr 1, at 17:07, JF Bastien <jfb at google.com> wrote:
> >
> > > 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!).
>
> But the typical clang user shouldn't suffer just because there are
> interesting use cases out there.  Cleanest and familiar are important.
>
> I'd be happy enough with a command-line option to specify "don't encode
> the target" to support this kind of thing.  Although Eric's idea from
> elsewhere in the thread seems better than adding a driver option:
>
>     $ 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
>
> In this scenario, I figure the Frontend would recognize `le64` as a
> special architecture whose target shouldn't get encoded in the IR... or
> the backend would recognize that it should be overwritten.
>
>
I think, in this sort of case, le64-unknown-unknown (or some such) is
actually going to be a decent sort of triple for the generic case. The
question is what to do at lto/codegen time as far as:

a) making them rewrite, or
b) allowing it to change from the outside as we were imagining for the llc
type of use case or
c) at least programmatically, i.e. if you explicitly construct a target
machine it'll override at least the triple

a seems the friendliest to us, b seems a little weird, but piggy backs on
our existing plans, c seems kinda fun and opens up some decent apis, but
I'm not sure about some of the longer term consequences.

Just some food for thought as we go through this.

-eric



> > >  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.
>
> I didn't say invalid :).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150402/c8e697ea/attachment.html>