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

Zheng CZ Chen via cfe-dev cfe-dev at lists.llvm.org
Thu Jan 17 04:20:20 PST 2019

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.

Chen Zheng
Power Compiler Backend Developer

----- Forwarded by Zheng CZ Chen/China/IBM on 2019/01/17 08:11 PM -----

From:	Chandler Carruth <chandlerc at gmail.com>
To:	Zheng CZ Chen <czhengsz at cn.ibm.com>
Cc:	Troy Johnson <troyj at cray.com>, "Finkel, Hal J."
            <hfinkel at anl.gov>, Roman Lebedev <lebedev.ri at gmail.com>,
            "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
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 <
llvm-dev at lists.llvm.org> wrote:

  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?


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


  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:


              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.


              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;

              return *a;

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

              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?


              Chen Zheng
              Power Compiler Backend Developer

              LLVM Developers mailing list
              llvm-dev at lists.llvm.org
  Hal Finkel
  Lead, Compiler Technology and Programming Languages
  Leadership Computing Facility
  Argonne National Laboratory

  LLVM Developers mailing list
  llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190117/8ac102f0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1B610340.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190117/8ac102f0/attachment.gif>

More information about the cfe-dev mailing list