[swift-evolution] More fine tuning optimization to swift compiler

[John McCall]

> On Aug 9, 2016, at 10:46 AM, Erik Eckstein via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Aug 9, 2016, at 10:19 AM, Wallacy via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I believe the -O is already able to loop unroll
> 
> correct
> 
>> , but now C-Style loop is gone, and maybe will be more "difficult" to compiler make this optimization, except of course using range literals.
>> 
>> Em ter, 9 de ago de 2016 às 13:10, Muse M via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> escreveu:
>> -Oloop
>> Correction: it should be similar to GCC -funroll-loops
>> On other option if we have 1,000,000's loops or array, it's bad for one core to handle 100% of the calculations and other cores are idle, the idea could be optimize loops to share/split workload across all available CPU cores. 
>> 
>> -Ofunction
>> Is a dummy example for other example.
>> 
>> On Tue, Aug 9, 2016 at 11:21 PM, Félix Cloutier <felixcca at yahoo.ca <mailto:felixcca at yahoo.ca>> wrote:
>> My understanding is that -Ounchecked removes integer overflow checks and array bound checks.
>> 
>> What type of optimizations would -Oloop and -Ofunction do?
>> 
>> Félix
>> 
>>> Le 7 août 2016 à 19:27:56, Muse M via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>> 
>>> I'm not sure if this is the right channel to discuss on optimization switch
>>> 
>>> We are aware the 3 options:
>>> -O
>>> -Ofast
>>> -Ounchecked
> 
> We have -O and -Ounchecked.
> -Ofast is obsolete.
> 
> 
>>> 
>>> As we can see, we rarely use -Ounchecked for safety reason and there aren't much info on what are the tradeoff. if there are performance reason that will need to improve loop or maths optimization or allow developers to fine-tuning in various area, we could add more options to compiler.
>>> 
>>> -OLoop (Optimize loop with safety)
>>> -OFunc (Optimize function calls)
>>> and so on.
>>> 
> 
> I think you are asking for a way to fine tune optimizations for a specific purpose.
> Fine-tuning optimizations is mostly intended for small parts of the code, like a function or even a loop.
> But optimization switches apply to the whole module (assuming whole-module-optimization). So an optimization switch is not really a good tool for fine tuning.
> 
> In general I believe there must be a good justification for adding an optimization switch/mode. E.g. it must be well understandable what it does and what's the difference to existing optimization modes.

Right.  Global optimization switches are generally a bad move; it's almost always better to have something more locally-scoped, like perhaps an OpenMP-like annotation on a loop encouraging it to be unrolled or parallelized.

John.

> 
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160809/da951700/attachment.html>