[swift-evolution] Optimization attributes

[Charles Kissinger]

Joe,

Thanks very much for the feedback. I accept your points, but just a few comments:

> It's easy to accidentally change behavior you didn't intend to by applying the attributes too broadly
Yes, but this was exactly the reason for proposing this as an alternative to the global compiler switch.

> It's also hard to define exactly what these mean, since many of the operations in question are defined as library functions.
But the -Ounchecked compiler switch already has a defined mechanism in place for eliding these function calls, correct?

>  I think it's better in general to use explicitly unsafe operations, for instance, using &+ instead of + to ignore overflow checks.
Agreed. The biggest problem with those operators is that they are a pain to scan through quickly and understand in even slightly more complex expressions. To take your equation below, translated to overflow operators:

return 4 &* x &* x &+ 2 &* x &+ 1

Yuck! All I see are the ampersands unless I squint. I had to read through it three times just to convince myself I translated the equation correctly.

> You could theoretically get something like the scoped attribute effect by using scoped imports, which could bring in a different set of operations shadowing the standard ones:
> 
> do {
>  import FastMath // FastMath.* now shadows Swift.*
> 
>  return 4*x*x + 2*x + 1
> }
Interesting approach. It would allow developers to implement a very limited set of “do-it-yourself” optimizations for some things. (I’m pretty sure DIY fast-math is out of the question though.)

Thanks again,
-CK

> 
> On Jan 7, 2016, at 4:04 PM, Joe Groff <jgroff at apple.com> wrote:
> 
> 
>> On Jan 7, 2016, at 1:55 PM, Charles Kissinger via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I wanted to float the idea of adding new attributes for function and method declarations that would allow various safety checks to be turned off (or on) at the level of individual functions. Examples of such attributes would be:
>> 
>> @uncheckedmath  // integer overflow
>> @uncheckedbounds  // array bounds
>> @unchecked      // no safety checks, equivalent to -Ounchecked
>> @fastmath         // if the —fastmath compiler option becomes available in the future
>> 
>> These attributes could have an argument with a value of true or false, allowing the global compiler option to be overridden for particular functions.
>> 
>> This is primarily motivated by the fact that the -Ounchecked compiler option is a very blunt instrument. It globally disables several unrelated safety checks such as integer overflow and array bounds checking. And it operates only at the level of an entire compilation unit. It is hard to reason about all the effects of this option across a large module, and isolating specific code to be compiled separately with -Ounchecked is inconvenient.
>> 
>> These new attributes would allow specific safety checks to be enabled or disabled on a per-function basis. I think the overall effect would be safer programs, because developers would be less likely to resort to the global -Ounchecked compiler option when searching for better performance.
>> 
>> Are optimization attributes such as these feasible?
> 
> Scoped semantics changes like this are problematic. It's easy to accidentally change behavior you didn't intend to by applying the attributes too broadly, and it's harder for readers to understand the behavior within the contextual modifiers. It's also hard to define exactly what these mean, since many of the operations in question are defined as library functions. I think it's better in general to use explicitly unsafe operations, for instance, using &+ instead of + to ignore overflow checks. You could theoretically get something like the scoped attribute effect by using scoped imports, which could bring in a different set of operations shadowing the standard ones:
> 
> do {
>  import FastMath // FastMath.* now shadows Swift.*
> 
>  return 4*x*x + 2*x + 1
> }
> 
> -Joe
>