[swift-evolution] Optimization Attributes for Automatic Reordering of Functions

[Charles Kissinger]

Modern optimizing compilers have a very robust understanding of algebraic rearrangement already built in, I think.

It can’t safely be done on floating point calculations, by the way, because the result of the calculation is likely to change (usually very slightly, sometimes catastrophically). Some compilers have a -fast-math option that (among other things) allows some floating point rearrangement for cases where the developer knows it is safe and gives acceptable results.

—CK

> On Jan 7, 2016, at 5:36 PM, Dave via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jan 7, 2016, at 13:55, 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
> 
> Oh! That reminds me! Can we add @associative, @commutative, and @distributive attributes to functions? Or at least to operators? I know it wouldn’t change anything *right now*, but it’d lay the groundwork for an entire new class of compiler optimizations. I think. Maybe they can already figure out stuff like this and I just don’t know about it.
> 
> For example, if the compiler knew that “*” could be distributed over “+”, then the compiler could rewrite this:
> 	let y = x*foo + x*bar
> to this:
> 	let y = x*(foo + bar)
> if it thinks that’s more efficient (which, I think it pretty much always would be for the native numeric types).
> 
> There’s an obvious danger in that overflows/underflows could be generated that wouldn’t have otherwise happened. However, this kind of rewriting could just as easily prevent them from happening, depending on the details.
> 
> Maybe the syntax could be tacked on the end of the definitions like this?
> func + (lhs: Integer, rhs: Integer) -> Integer {
> 	…
> } @commutative @associative
> 
> func * (lhs: Integer, rhs: Integer) -> Integer {
> 	…
> } @commutative @associative @distributive over (+ - * /) // whitespace-delimited so that it won’t matter if an operator ends with a comma 
> 
> Or maybe make it kinda sorta similar to an extension? (Although separating “the rules that tell the compiler how it’s allowed to literally rewrite your code” from “the functions to which said rules apply" seems like a bad idea)
> @attributes infix operator + {
> 	func + (_: Integer, _: Integer) -> Integer @commutative @associative
> }
> @attributes infix operator * {
> 	func * (_: Integer, _: Integer) -> Integer @commutative @associative @distributive over (+ - * /)
> }
> 
> I think my favorite would be between the return type and the opening curly brace:
> func + (lhs: Integer, rhs: Integer) -> Integer @commutative @associative {
> 	…
> }
> func * (lhs: Integer, rhs: Integer) -> Integer @commutative @associative @distributive over (+ - * /) {
> 	…
> }
> 
> Going a step (or two) further, for funcs/ops that *aren’t* <any given attribute>, it could conceivably help to be able to optionally express a way to sorta fake it. For instance, while “a-b” usually doesn’t equal “b-a”, it does equal “-(b-a)”. Similarly, a/b is equal to 1/(b/a). (I know commutativity isn’t a particularly good example, since that attribute doesn’t affect when values need to be known, operand grouping, or the total number of operations, but I couldn’t think of any examples of the other types.) I’m much less supportive of this part… I think it’d be *cool*, but I have no idea if it’d be *useful*. It just seems to me that the more metadata we can give the compiler, the more opportunities it’ll have to optimize our code.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution