[llvm-dev] Whither/whether -mtune support?

[Eric Christopher via llvm-dev]

On Thu, Oct 26, 2017 at 11:00 AM Matthias Braun <mbraun at apple.com> wrote:

> Sounds sensible. I'd be happy to look at detailed patches.
>
> I'd like to point out that target features are already used for tuning
> settings today (and that's fine I think). So maybe this doesn't need to be
> much more than just an extra way to initialize target features.
>
>
It is, I'd like to move the tuning parameters aside and basically
initialize tune to arch/cpu (why ARM? why?) if it's not already set :)

-eric



> - Matthias
>
> On Oct 20, 2017, at 3:16 PM, Eric Christopher via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hi All,
>
> I've gotten a few notes over the last few months and also given some of
> the recent changes to various backends to "update" the default tunings for
> a generic processor it made me think again about adding support for tuning
> to a processor rather than generating processor specific code - hence,
> mtune. I hope this is rather uncontroversial, but happy to discuss at
> length if anyone thinks we shouldn't add this functionality to the compiler.
>
> That said, I have a bit of a strawman outline for what I think needs to
> happen in general, and while I don't have any concrete plans to attack this
> soon I thought I'd post it in case someone else was interested:
>
> a) split out (in targets where we care) code generation features from
> tuning features on a per subtarget basis into a separate set of features
> b) add support for initializing them based on a tune parameter to the
> subtarget
> c) add support to clang for generating the tune parameter on a per
> function basis
> d) Use them in TTI and various other backend hooks rather than any code
> gen specific ones.
>
> Simple right? :) I'm happy to elaborate here, but I believe the work is
> relatively straight forward if a lot of typing.
>
> Every step there is likely to be a lot more complicated, but similar to
> the getSubtarget<>/getSubtargetImpl changes it should be very easy to do on
> any particular backend and fan out support there. Just make sure that clang
> knows which targets do and don't support the flag.
>
> Happy to help or review work here.
>
> Thanks!
>
> -eric
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171026/3ddaccf2/attachment.html>