[llvm-dev] Aggressive optimization opportunity

[Finkel, Hal J. via llvm-dev]

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>