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

[Krzysztof Parzyszek via llvm-dev]

Hi Eric,

This is interesting, and we (Hexagon) were thinking about something that 
would allow passing extra information aside from the CPU. The main (but 
not the only) motivation was related to scheduling: single-threaded vs 
multi-threaded.
Another case could be specifying cache configuration: sizes of L1, L2, 
and some additional info, like TCM size for example.

What are your thoughts on allowing features to have non-boolean values?

-Krzysztof

On 10/20/2017 5:16 PM, Eric Christopher via llvm-dev 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
> 
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> 	Virus-free. www.avg.com 
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> 
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>