search for: externally_avail

...t completely understand the problem, but this seems like overkill. The underlying restriction is that, if the compiler makes a non-determinism-collapsing choice when optimizing a function, it must make the same choice for all definitions of that function (undefined behavior excluded). Thus, with an externally_available function, the CSE in Sanjoy's original example should be forbidden. Richard's example again demonstrates this principle, although in this case the non-determinism is in the choice of a globally-visible implementation technique rather than non-determinism from memory-subsystem reordering...

...functions, which you can't do. The result would be failing to optimize the bodies of linkonce_odr functions in any way which was externally detectable such as this. I think that would be *much* worse than losing the ability to do function attribute deduction for such functions? Thus, with an externally_available function, the CSE in Sanjoy's original > example should be forbidden. Richard's example again demonstrates this > principle, although in this case the non-determinism is in the choice of a > globally-visible implementation technique rather than non-determinism from > memory-...

...rently foo(). > > The result would be failing to optimize the bodies of linkonce_odr functions in any way which was externally detectable such as this. I think that would be *much* worse than losing the ability to do function attribute deduction for such functions? > > Thus, with an externally_available function, the CSE in Sanjoy's original example should be forbidden. Richard's example again demonstrates this principle, although in this case the non-determinism is in the choice of a globally-visible implementation technique rather than non-determinism from memory-subsystem reordering...

...ing to optimize the bodies of linkonce_odr > > functions in any way which was externally detectable such as this. > > I > > think that would be *much* worse than losing the ability to do > > function attribute deduction for such functions? > > > > Thus, with an externally_available function, the CSE in Sanjoy's > > > original example should be forbidden. Richard's example again > > > demonstrates this principle, although in this case the > > > non-determinism is in the choice of a globally-visible > > > implementation technique...

...ies of linkonce_odr >>> functions in any way which was externally detectable such as this. >>> I >>> think that would be *much* worse than losing the ability to do >>> function attribute deduction for such functions? >> > >>>> Thus, with an externally_available function, the CSE in Sanjoy's >>>> original example should be forbidden. Richard's example again >>>> demonstrates this principle, although in this case the >>>> non-determinism is in the choice of a globally-visible >>>> implementation te...

...functions? But it is not all optimizations that are the problem. Rather, it seems like a select few (e.g. things involving collapsing allowed non-determinism in atomics), and losing those optimizations seems better than generally losing function-attribute deduction. -Hal > > Thus, with an externally_available function, the CSE in Sanjoy's > > original example should be forbidden. Richard's example again > > demonstrates this principle, although in this case the > > non-determinism is in the choice of a globally-visible > > implementation technique rather than non-dete...

Yea, I'm pretty sad about all of this. I'm also not seeing a lot of awesome paths forward. Here is the least bad strategy I can come up with. Curious if folks think this is sufficient: 1) Stop deducing function attributes within comdats by examining the bodies of the functions (so that we remain free to transform the bodies of functions). 2) Teach frontends to emit (even at O0!!!)

On 02/24/2016 08:10 PM, Duncan P. N. Exon Smith via llvm-dev wrote: >> On 2016-Feb-24, at 19:46, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: >> >> On Wed, Feb 24, 2016 at 7:38 PM, Chandler Carruth <chandlerc at google.com> wrote: >>> On Wed, Feb 24, 2016 at 7:34 PM Duncan P. N. Exon Smith >>> <dexonsmith at apple.com> wrote: