www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Article on overzealous compiler optimizations

reply Walter Bright <newshound2 digitalmars.com> writes:
http://developers.slashdot.org/story/14/06/20/1824226/overeager-compilers-can-open-security-holes-in-your-code

This is an opportunity for D to define the spec in such away as to preclude the 
bad optimizations while keeping the good ones. Any ideas?
Jun 20 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/20/2014 3:20 PM, Walter Bright wrote:
 http://developers.slashdot.org/story/14/06/20/1824226/overeager-compilers-can-open-security-holes-in-your-code


 This is an opportunity for D to define the spec in such away as to preclude the
 bad optimizations while keeping the good ones. Any ideas?

Better link: http://css.csail.mit.edu/stack/
Jun 20 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 This is an opportunity for D to define the spec in such away as 
 to preclude the bad optimizations while keeping the good ones. 
 Any ideas?

Such optimizations are one of the causes that make memory-unsafe the D reliance of null pointer segfaults, even in safe functions. Bye, bearophile
Jun 20 2014
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/21/2014 12:20 AM, Walter Bright wrote:
 http://developers.slashdot.org/story/14/06/20/1824226/overeager-compilers-can-open-security-holes-in-your-code


 This is an opportunity for D to define the spec in such away as to
 preclude the bad optimizations while keeping the good ones. Any ideas?

A possibility is to have no undefined behaviour in standard language features and to add unsafe intrinsics for the cases where the optimizer _actually_ needs the help for generating fast enough code for a hot spot. (Of course, a type system that is able to preclude more of the bad behaviours in the first place can help too.) E.g. int foo(Foo* foo) safe{ return foo.bar; // defined behaviour in all cases } int bar(Foo* foo) system{ return __assume_non_null(foo).bar; // undefined behaviour if foo is null }
Jun 20 2014
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, June 20, 2014 15:20:17 Walter Bright via Digitalmars-d wrote:
 http://developers.slashdot.org/story/14/06/20/1824226/overeager-compilers-ca
 n-open-security-holes-in-your-code

 This is an opportunity for D to define the spec in such away as to preclude
 the bad optimizations while keeping the good ones. Any ideas?

I applaud the sentiment, but I fear that I don't know enough about compiler optimizations to have much in the way of good ideas. It seems like every time the subject comes up, it turns out that compilers do all kinds of crazy things that make it so that half of what you think is guaranteed isn't guaranteed. If you had some way to mark code such that it restricts what the compiler can optimize, then that could help, but you'd have to know that you needed that restriction in the first place, and usually, the problem is that you don't even know what the compiler might optimize out, and not even checking the generated assembly helps in the general case, because what one compiler might leave in, another might optimize out. It's a thorny problem. - Jonathan M Davis
Jun 22 2014
parent Shammah Chancellor <anonymous coward.com> writes:
On 2014-06-22 19:32:45 +0000, Jonathan M Davis via Digitalmars-d said:

 On Friday, June 20, 2014 15:20:17 Walter Bright via Digitalmars-d wrote:
 http://developers.slashdot.org/story/14/06/20/1824226/overeager-compilers-ca
 n-open-security-holes-in-your-code
 
 This is an opportunity for D to define the spec in such away as to preclude
 the bad optimizations while keeping the good ones. Any ideas?

I applaud the sentiment, but I fear that I don't know enough about compiler optimizations to have much in the way of good ideas. It seems like every time the subject comes up, it turns out that compilers do all kinds of crazy things that make it so that half of what you think is guaranteed isn't guaranteed. If you had some way to mark code such that it restricts what the compiler can optimize, then that could help, but you'd have to know that you needed that restriction in the first place, and usually, the problem is that you don't even know what the compiler might optimize out, and not even checking the generated assembly helps in the general case, because what one compiler might leave in, another might optimize out. It's a thorny problem. - Jonathan M Davis

Sounds like the oracle query optimizer. 95% of the time it does the right thing, but convincing it to behave the other 5% of the time is a real trick. -Shammah
Jun 23 2014