> On Aug 9, 2016, at 10:46 AM, Erik Eckstein via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Aug 9, 2016, at 10:19 AM, Wallacy via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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 <felix...@yahoo.ca >> <mailto:felix...@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
