Fw: [llvm-dev] Aggressive optimization opportunity

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Fw: [llvm-dev] Aggressive optimization opportunity

David Blaikie via cfe-dev

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 -----

From: Chandler Carruth <[hidden email]>
To: Zheng CZ Chen <[hidden email]>
Cc: Troy Johnson <[hidden email]>, "Finkel, Hal J." <[hidden email]>, Roman Lebedev <[hidden email]>, "[hidden email]" <[hidden email]>
Date: 2019/01/16 12:20 PM
Subject: Re: [llvm-dev] Aggressive optimization opportunity





This isn't really a discussion about LLVM any longer. LLVM has the ability to model pointer parameters with the desired semantics.

This is now a question about a C/C++ extension to Clang. That discussion would probably be best held on cfe-dev where there are more folks focused on the language and frontend. 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++, but it may be worth asking the correct audience that question. =]

On Tue, Jan 15, 2019 at 6:57 PM Zheng CZ Chen via llvm-dev <[hidden email]> wrote:
    Hi,

    Very appreciate for all your input.


    it is indeed a very aggressive optimization and it is not safe in many cases. But it should be helpful to tune application's performance if it is safe.


    I think if we want to support it, we must:
    1: only let compiler user turn it on by explicitly specifying -fforce-restrict-ptr-args, otherwise it is always off.
    2: emit a warning message to remind this opt will change program semantics if users turn it on.
    3: restrict its application to C/C++.


    Any ideas?


    Thanks.


    BRS//
    Chen Zheng
    Power Compiler Backend Developer



    Inactive hide details for Troy Johnson ---2019/01/16 02:32:22 AM---Restrict is supported by Clang for C++ via __restrict__, soTroy Johnson ---2019/01/16 02:32:22 AM---Restrict is supported by Clang for C++ via __restrict__, so it seems strange to block using this pro

    From:
    Troy Johnson <[hidden email]>
    To:
    "Finkel, Hal J." <[hidden email]>, Zheng CZ Chen <[hidden email]>
    Cc:
    "[hidden email]" <[hidden email]>
    Date:
    2019/01/16 02:32 AM
    Subject:
    RE: [llvm-dev] Aggressive optimization opportunity




    Restrict is supported by Clang for C++ via __restrict__, so it seems strange to block using this proposed option for C++.


    That said, this kind of option can be dangerous and should come with a suitable warning. We’ve had a similar option and in practice it’s been used to hunt for performance gains (i.e., turn it on and see what happens), but just because the code runs faster and produces the correct result with the option enabled doesn’t mean it is safe in all cases. And if it crashes or gives you wrong answers, you still don’t know which pointer had the alias that caused that problem. Either way, you still need to inspect all of the pointers and prove to yourself it is safe and at that point you might as well add restrict manually.


    -Troy


    From:
    llvm-dev <[hidden email]> On Behalf Of Finkel, Hal J. via llvm-dev
    Sent:
    Tuesday, January 15, 2019 9:57 AM
    To:
    Zheng CZ Chen <[hidden email]>; [hidden email]
    Subject:
    Re: [llvm-dev] Aggressive optimization opportunity


    On 1/15/19 6:07 AM, Zheng CZ Chen via llvm-dev wrote:

            Hi,

            There are some compilers with a aggressive optimization which restricts function pointer parameters. Let's say opt restrict_args. When restrict_args is turned on, compiler will treat all function pointer parameters as restrict one.
    I certainly understand the use case, in a general sense. In my experience, these options are used with (fairly old) pre-C99 code bases (and specifically C, not C++), which follow something akin to a one-function-per-source-file model and which can't be modified (e.g., for licensing reasons). Using these options are certainly considered bad practice, and they only apply to certain legacy code bases. Does this match your experience and expected usage?

    In an engineering sense, this seems like a trivial feature to support. I don't object to supporting it, but if we do, we probably want to:

    1. Restrict it's application to C (e.g., it should be an error to use with C++, OpenCL, CUDA, and any other languages that Clang supports).

    2. When used with C99 or later language standards, the use of this flag generates a warning on each function definition with a fixit hint showing where the restrict keyword should be placed (we can then, optionally of course, use these fixits to automatically upgrade code where possible using our corresponding infrastructure). This warning should have a separate flag, and is disabled by default for pre-C99 standard modes, and enabled by default otherwise, but can be toggled independently.

    -Hal


            int foo(int * a)
            + restrict_args opt

            equals to:


            int foo(int * restrict a)



            Here is a complete example:
            source code:
            extern int num;

            int foo(int * a)
            {
            (*a) = 10;
            num++;
            (*a)++;

            return *a;
            }


            Using IBM xlc compiler with option -qrestrict at -O2, we get result:

            0000000000000000 <foo>:
            0: 00 00 4c 3c addis r2,r12,0
            4: 00 00 42 38 addi r2,r2,0
            8: 00 00 a2 3c addis r5,r2,0
            c: 00 00 a5 e8 ld r5,0(r5)
            10: 0b 00 00 38 li r0,11
            14: 00 00 03 90 stw r0,0(r3)
            18: 00 00 85 80 lwz r4,0(r5)

            1c: 0b 00 60 38 li r3,11 ------>since we confirm num will not change the content where pointer to, compiler can directly return 11.

            20: 01 00 04 38 addi r0,r4,1
            24: 00 00 05 90 stw r0,0(r5)
            28: 20 00 80 4e blr

            Seems clang does not have such optimization. And I don't find similar option in gcc either.

            Is it possible to add this optimization into clang?

            Thanks.

            BRS//
            Chen Zheng
            Power Compiler Backend Developer



            _______________________________________________
            LLVM Developers mailing list

            [hidden email]
            http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
    --
    Hal Finkel
    Lead, Compiler Technology and Programming Languages
    Leadership Computing Facility
    Argonne National Laboratory



    _______________________________________________
    LLVM Developers mailing list
    [hidden email]
    http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

David Blaikie via cfe-dev


On 1/17/19 6:20 AM, Zheng CZ Chen via cfe-dev wrote:

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 -----

From: Chandler Carruth [hidden email]
To: Zheng CZ Chen [hidden email]
Cc: Troy Johnson [hidden email], "Finkel, Hal J." [hidden email], Roman Lebedev [hidden email], [hidden email] [hidden email]
Date: 2019/01/16 12:20 PM
Subject: Re: [llvm-dev] Aggressive optimization opportunity





This isn't really a discussion about LLVM any longer. LLVM has the ability to model pointer parameters with the desired semantics.

This is now a question about a C/C++ extension to Clang. That discussion would probably be best held on cfe-dev where there are more folks focused on the language and frontend. 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++, but it may be worth asking the correct audience that question. =]

On Tue, Jan 15, 2019 at 6:57 PM Zheng CZ Chen via llvm-dev <[hidden email]> wrote:
    Hi,

    Very appreciate for all your input.


    it is indeed a very aggressive optimization and it is not safe in many cases. But it should be helpful to tune application's performance if it is safe.


    I think if we want to support it, we must:
    1: only let compiler user turn it on by explicitly specifying -fforce-restrict-ptr-args, otherwise it is always off.
    2: emit a warning message to remind this opt will change program semantics if users turn it on.
    3: restrict its application to C/C++.


    Any ideas?


    Thanks.


    BRS//
    Chen Zheng
    Power Compiler Backend Developer



    Inactive
          hide details for Troy Johnson ---2019/01/16 02:32:22
          AM---Restrict is supported by Clang for C++ via __restrict__,
          soTroy Johnson ---2019/01/16 02:32:22 AM---Restrict is supported by Clang for C++ via __restrict__, so it seems strange to block using this pro

    From:
    Troy Johnson <[hidden email]>
    To:
    "Finkel, Hal J." <[hidden email]>, Zheng CZ Chen <[hidden email]>
    Cc:
    "[hidden email]" <[hidden email]>
    Date:
    2019/01/16 02:32 AM
    Subject:
    RE: [llvm-dev] Aggressive optimization opportunity




    Restrict is supported by Clang for C++ via __restrict__, so it seems strange to block using this proposed option for C++.


    That said, this kind of option can be dangerous and should come with a suitable warning. We’ve had a similar option and in practice it’s been used to hunt for performance gains (i.e., turn it on and see what happens), but just because the code runs faster and produces the correct result with the option enabled doesn’t mean it is safe in all cases. And if it crashes or gives you wrong answers, you still don’t know which pointer had the alias that caused that problem. Either way, you still need to inspect all of the pointers and prove to yourself it is safe and at that point you might as well add restrict manually.


    -Troy


    From:
    llvm-dev <[hidden email]> On Behalf Of Finkel, Hal J. via llvm-dev
    Sent:
    Tuesday, January 15, 2019 9:57 AM
    To:
    Zheng CZ Chen <[hidden email]>; [hidden email]
    Subject:
    Re: [llvm-dev] Aggressive optimization opportunity


    On 1/15/19 6:07 AM, Zheng CZ Chen via llvm-dev wrote:

            Hi,

            There are some compilers with a aggressive optimization which restricts function pointer parameters. Let's say opt restrict_args. When restrict_args is turned on, compiler will treat all function pointer parameters as restrict one.
    I certainly understand the use case, in a general sense. In my experience, these options are used with (fairly old) pre-C99 code bases (and specifically C, not C++), which follow something akin to a one-function-per-source-file model and which can't be modified (e.g., for licensing reasons). Using these options are certainly considered bad practice, and they only apply to certain legacy code bases. Does this match your experience and expected usage?

    In an engineering sense, this seems like a trivial feature to support. I don't object to supporting it, but if we do, we probably want to:

    1. Restrict it's application to C (e.g., it should be an error to use with C++, OpenCL, CUDA, and any other languages that Clang supports).

    2. When used with C99 or later language standards, the use of this flag generates a warning on each function definition with a fixit hint showing where the restrict keyword should be placed (we can then, optionally of course, use these fixits to automatically upgrade code where possible using our corresponding infrastructure). This warning should have a separate flag, and is disabled by default for pre-C99 standard modes, and enabled by default otherwise, but can be toggled independently.

    -Hal


            int foo(int * a)
            + restrict_args opt

            equals to:


            int foo(int * restrict a)



            Here is a complete example:
            source code:
            extern int num;

            int foo(int * a)
            {
            (*a) = 10;
            num++;
            (*a)++;

            return *a;
            }


            Using IBM xlc compiler with option -qrestrict at -O2, we get result:

            0000000000000000 <foo>:
            0: 00 00 4c 3c addis r2,r12,0
            4: 00 00 42 38 addi r2,r2,0
            8: 00 00 a2 3c addis r5,r2,0
            c: 00 00 a5 e8 ld r5,0(r5)
            10: 0b 00 00 38 li r0,11
            14: 00 00 03 90 stw r0,0(r3)
            18: 00 00 85 80 lwz r4,0(r5)

            1c: 0b 00 60 38 li r3,11 ------>since we confirm num will not change the content where pointer to, compiler can directly return 11.

            20: 01 00 04 38 addi r0,r4,1
            24: 00 00 05 90 stw r0,0(r5)
            28: 20 00 80 4e blr

            Seems clang does not have such optimization. And I don't find similar option in gcc either.

            Is it possible to add this optimization into clang?

            Thanks.

            BRS//
            Chen Zheng
            Power Compiler Backend Developer



            _______________________________________________
            LLVM Developers mailing list

            [hidden email]
            http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
    --
    Hal Finkel
    Lead, Compiler Technology and Programming Languages
    Leadership Computing Facility
    Argonne National Laboratory



    _______________________________________________
    LLVM Developers mailing list
    [hidden email]
    http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

David Blaikie via cfe-dev
"Finkel, Hal J. via cfe-dev" <[hidden email]> 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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev