thr3ads.net - llvm dev - [llvm-dev] Aggressive optimization opportunity [Jan 2019]

If this information is useful, please help other people find it:
Share via:

Troy Johnson via llvm-dev

2019-Jan-15 18:31 UTC

[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 <llvm-dev-bounces at lists.llvm.org> On Behalf Of Finkel,
Hal J. via llvm-dev
Sent: Tuesday, January 15, 2019 9:57 AM
To: Zheng CZ Chen <czhengsz at cn.ibm.com>; llvm-dev at lists.llvm.org
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

llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>

http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

--

Hal Finkel

Lead, Compiler Technology and Programming Languages

Leadership Computing Facility

Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190115/9f8d961e/attachment-0001.html>

Krzysztof Parzyszek via llvm-dev

2019-Jan-15 18:53 UTC

head link

[llvm-dev] Aggressive optimization opportunity

On 1/15/2019 12:31 PM, Troy Johnson via llvm-dev wrote:> Restrict is supported by Clang for C++ via __restrict__, so it seems 
> strange to block using this proposed option for C++.
In C the functions whose code the compiler will compile typically come 
from the application's sources. In C++ there is usually a lot more code 
coming from the standard library and other template-based headers. Even 
if you apply that option to selected source files, you may end up with 
two different instatiations of the same template: unsafe (compiled with 
"restrict") and safe (without "restrict"). If template
instatiations are
marked as "weak", in the end the unsafe versions may end up being used
where the safe versions are required.

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

Zheng CZ Chen via llvm-dev

2019-Jan-16 02:56 UTC

head link

[llvm-dev] Aggressive optimization opportunity

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




From:	Troy Johnson <troyj at cray.com>
To:	"Finkel, Hal J." <hfinkel at anl.gov>, Zheng CZ Chen
            <czhengsz at cn.ibm.com>
Cc:	"llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
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 <llvm-dev-bounces at lists.llvm.org> On Behalf Of Finkel,
Hal
J. via llvm-dev
Sent: Tuesday, January 15, 2019 9:57 AM
To: Zheng CZ Chen <czhengsz at cn.ibm.com>; llvm-dev at lists.llvm.org
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
      llvm-dev at lists.llvm.org
      http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190116/92922192/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190116/92922192/attachment.gif>

Chandler Carruth via llvm-dev

2019-Jan-16 04:20 UTC

head link

[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 <
llvm-dev at lists.llvm.org> 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
>
>
> [image: Inactive hide details for Troy Johnson ---2019/01/16 02:32:22
> AM---Restrict is supported by Clang for C++ via __restrict__, so]Troy
> 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 <troyj at cray.com>
> To: "Finkel, Hal J." <hfinkel at anl.gov>, Zheng CZ Chen
<czhengsz at cn.ibm.com
> >
> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at
lists.llvm.org>
> 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 <llvm-dev-bounces at lists.llvm.org> *On Behalf Of
*Finkel,
> Hal J. via llvm-dev
> *Sent:* Tuesday, January 15, 2019 9:57 AM
> *To:* Zheng CZ Chen <czhengsz at cn.ibm.com>; llvm-dev at
lists.llvm.org
> *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
>       *llvm-dev at lists.llvm.org* <llvm-dev at lists.llvm.org>
>       *http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev*
>       <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
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190115/4b336d11/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190115/4b336d11/attachment.gif>

llvm dev - Jan 2019 - Aggressive optimization opportunity

[llvm-dev] Aggressive optimization opportunity

[llvm-dev] Aggressive optimization opportunity

[llvm-dev] Aggressive optimization opportunity

[llvm-dev] Aggressive optimization opportunity