[swift-dev] deprecating -Ounchecked

[Erik Eckstein]

> On Nov 2, 2017, at 10:51 AM, Johannes Weiß <johannesweiss at apple.com> wrote:
> 
> Definitely a +1 from me, a haven't recently seen much of a difference either.
> 
> Said that I do sometimes use it in a micro-benchmark just to convince myself we don't lose much performance on the checks. Usually it turns out fine, I'm happy and move on. But I guess there's some value in being able to elide a lot of checks just to see how much of a difference it does. And if there's a big difference then I'd try to optimise the program and elide unnecessary checks myself. Clearly -Ounchecked should never be used in any real code but I find having a baseline when optimising performance very helpful and -Ounchecked sometimes seemed like a cheap, automatic baseline for some code ;).
> 
> And lastly I always thought having it as an 'optimisation' is a misnomer, it's not an optimisation as it clearly changes the semantics of the program quite a bit. I thought '-unsafe-remove-checks' or something describes it better, a bit like '-assume-single-threaded’.

I like that idea. We could add such an option.

Daniel, I think that’s also what you were asking for.


> But probably the 'no checks' mode adds too much complexity to just keep it around for a questionable way to do performance baselines.
> 
>> On 2 Nov 2017, at 9:52 am, Erik Eckstein via swift-dev <swift-dev at swift.org> wrote:
>> 
>> Hi,
>> 
>> I’d like to propose to deprecate the -Ounchecked swift optimization mode.
>> 
>> The -Ounchecked mode actually contradicts one of the main goals of swift: to be a safe language.
>> In the past we didn’t see lot of significant performance differences compared to -O (there were some improvements but also some regressions).
>> Also, we want to reduce the effort of maintaining too many different optimization modes, especially because we recently added -Osize.
>> 
>> Deprecating would mean that we map -Ounchecked to -O.
>> 
>> If you have any comments or concerns, please let me know
>> 
>> Thanks,
>> Erik
>> 
>> 
>> 
>> _______________________________________________
>> swift-dev mailing list
>> swift-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-dev
>