[llvm-dev] Aggressive optimization opportunity

[Roman Lebedev via llvm-dev]

On Tue, Jan 15, 2019 at 4:03 PM Zheng CZ Chen <czhengsz at cn.ibm.com> wrote:

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

Thanks.
>
> BRS//
> Chen Zheng
> Power Compiler Backend Developer
>
>
> [image: Inactive hide details for Roman Lebedev ---2019/01/15 08:43:06
> PM---On Tue, Jan 15, 2019 at 3:08 PM Zheng CZ Chen via llvm-dev]Roman
> Lebedev ---2019/01/15 08:43:06 PM---On Tue, Jan 15, 2019 at 3:08 PM Zheng
> CZ Chen via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> 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 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 Developer
> Roman.
>
> > _______________________________________________
> > 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/3584f33e/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/3584f33e/attachment.gif>