[cfe-dev] Fw: [llvm-dev] Aggressive optimization opportunity

[David Greene via cfe-dev]

"Finkel, Hal J. via cfe-dev" <cfe-dev at lists.llvm.org> writes:

> I completely agree, however in this particular case, I look at it
> differently: There does exist a non-trivial body of code that compiles
> using these flags, and currently must continue to do so for
> performance reasons, and should we provide that code with a path
> toward using modern compilers, and importantly, a migration path away
> from using these non-standard semantics? I believe the answer is yes.
> Given that we can issue warnings and provide fixits, which can be
> automatically applied at some point in the code-modernization process,
> (if that's possible) I think that we can do this in a way that
> provides a practical migration path. There is also legacy code that we
> can't change, and as a practical matter, support is useful (as it
> allows is to otherwise take advantage of more-modern compiler
> technology).
>
> As I stated below, this functionality *must* come with an appropriate
> set of warnings and the like.
>
> Also, to be clear, my opinion here is colored by the belief that this
> can be implemented and maintained with very low engineering overhead.

In addition to the "restrict all pointer arguments," our C++ compiler
has an option to apply restrict to "this," as if the user had put
__restrict__ at the end of the function signature.  I'm not sure how
much it's actually used but it was added at some point for presumably
some reason.  If we're considering the current proposal then possibly we
should consider this extension to it.  Someone more knowledgeable about
how legacy C++ codes are maintained than this dumb compiler engineer
should probably chime in.  :)

We also have a mode that says, "Damn the torpedoes, full restrict
ahead!" in which the compiler gleefully applies restrict to everything
imaginable.  I would not recommend it for clang.  :)

                             -David