Zheng CZ Chen via llvm-dev
2019-Jan-15 12:07 UTC
[llvm-dev] Aggressive optimization opportunity
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190115/3d99adf6/attachment.html>
Roman Lebedev via llvm-dev
2019-Jan-15 12:42 UTC
[llvm-dev] Aggressive optimization opportunity
On Tue, Jan 15, 2019 at 3:08 PM Zheng CZ Chen via llvm-dev <llvm-dev at lists.llvm.org> 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. > > 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?E.g. https://godbolt.org/z/gB98K0> Thanks. > > BRS// > Chen Zheng > Power Compiler Backend DeveloperRoman.> _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Zheng CZ Chen via llvm-dev
2019-Jan-15 13:02 UTC
[llvm-dev] Aggressive optimization opportunity
Yes, the same result. But the way in your link is to change source code. My proposal is to add a compiling option like -fforce-restrict-ptr-args to clang and not change user source code. Thanks. BRS// Chen Zheng Power Compiler Backend Developer From: Roman Lebedev <lebedev.ri at gmail.com> To: Zheng CZ Chen <czhengsz at cn.ibm.com> Cc: llvm-dev at lists.llvm.org Date: 2019/01/15 08:43 PM Subject: Re: [llvm-dev] Aggressive optimization opportunity On Tue, Jan 15, 2019 at 3:08 PM Zheng CZ Chen via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Hi, > > There are some compilers with a aggressive optimization which restrictsfunction pointer parameters. Let's say opt restrict_args. When restrict_args is turned on, compiler will treat all function pointer parameters as restrict one.> > 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 thecontent 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 similaroption in gcc either.> > Is it possible to add this optimization into clang?E.g. https://godbolt.org/z/gB98K0> Thanks. > > BRS// > Chen Zheng > Power Compiler Backend DeveloperRoman.> _______________________________________________ > 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/45d0c6de/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/45d0c6de/attachment.gif>
Finkel, Hal J. via llvm-dev
2019-Jan-15 15:56 UTC
[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/9b611bfb/attachment.html>
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>