[llvm-dev] Aggressive optimization opportunity (original) (raw)

Roman Lebedev via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 15 05:15:32 PST 2019

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 restrictargs. When restrictargs is turned on, compiler will treat all function pointer parameters as restrict one. > > int foo(int * a) + restrictargs 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? 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>

More information about the llvm-dev mailing list