Aggressive optimization opportunity

Project Infrastructure LLVM Dev List Archives
1

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

2

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. Compiler Explorer

Thanks.

BRS//
Chen Zheng
Power Compiler Backend Developer

Roman.

3

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

graycol.gif

4

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.

Oh, i see, missed that, sorry.
To me that sounds a bit too brittle/easy to break stuff,
plus all the usual arguments about creating new language dialect //may// apply.

Though i wonder, is it feasible to have some sanitizer to catch the cases when
the compiler does some transform based on an assumption of non-aliasing,
while that assumption ends up being incorrect at run-time.

To be noted, there are some more low-level missing blocks missing,
e.g. the llvm.noalias patchset (https://reviews.llvm.org/D9375 & follow-ups)
^ really looking forward to that one.

graycol.gif

5

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

6

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

7

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

8

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

graycol.gifTroy 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

9

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. =]

graycol.gif

10

Thanks, Chandler. I have forwarded it to cfe-dev.

Thanks.

BRS//
Chen Zheng
Power Compiler Backend Developer

graycol.gifChandler Carruth —2019/01/16 12:20:23 PM—This isn’t really a discussion about LLVM any longer. LLVM has the ability to model pointer paramete