Aggressive optimization opportunity

Hi guys,

I posted this discussion and some one said this should be discussed in cfe-dev. So forward it here, sorry for the long mail.

My question is: is it possible to add a clang option to make cfe set all function pointer parameters with restrict attribute as if user add a keyword ‘restrict’ for this parameter?

Reason why I make this proposal is because some compiler like IBM XL has similar option -qrestrict for performance tuning.
If we confirm functionality is right, adding this kind of option will make application run faster. There is a small example in my first mail.

Thanks in advance and look forward to your answer.

BRS//
Chen Zheng
Power Compiler Backend Developer

----- Forwarded by Zheng CZ Chen/China/IBM on 2019/01/17 08:11 PM -----

graycol.gif

Hi guys,

I posted this discussion and some one said this should be discussed in cfe-dev. So forward it here, sorry for the long mail.

My question is: is it possible to add a clang option to make cfe set all function pointer parameters with restrict attribute as if user add a keyword 'restrict' for this parameter?

Reason why I make this proposal is because some compiler like IBM XL has similar option -qrestrict for performance tuning.
If we confirm functionality is right, adding this kind of option will make application run faster. There is a small example in my first mail.

Thanks in advance and look forward to your answer.

You can find my original response below, and I still believe that, in the restricted sense I outlined, this is reasonable for us to support (although I take Troy's point that we could accept this in C++ mode with the same warnings as for modern C - and I do want to encourage migration to C++).

Regarding Chandler's comment:

My suspicion is that there will be very little desire for an extension that knowingly and intentionally breaks very basic properties of C and C++

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.

Thanks again,

Hal

BRS//
Chen Zheng
Power Compiler Backend Developer

----- Forwarded by Zheng CZ Chen/China/IBM on 2019/01/17 08:11 PM -----

graycol.gif

"Finkel, Hal J. via cfe-dev" <cfe-dev@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. :slight_smile:

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. :slight_smile:

                             -David