William Moses via llvm-dev
2019-Jul-23 23:46 UTC
[llvm-dev] [RFC] Optimization Remark for derived function / argument attributes
Hello all, During the compilation process, LLVM automatically derives various attributes about functions and values (for example that a pointer is nonnull, a function is constant, etc) that are used within a translation unit. I propose adding a pass to LLVM that allows front-ends to output derived attributes. Such a pass would be useful both for developers and end users to debug programs, either learning that an expected attribute was learned, or an unexpected attribute was learned (for example a pointer never being written to). Evidently the following might not be the final interface, but one could imagine something like the following: $ ./clang foobar.c -g -Rannotations -O3 foobar.c:2:1: remark: derived following attributes for function f: fn_attr("norecurse") fn_attr("nounwind") fn_attr("readonly") arg_attr(0, "nocapture") arg_attr(0, "readonly") [-Rannotations] double f(double* a) { foobar.c: double f(double* a) { return a[0]; } A work in progress patch implementing such an optimization remark is available here: https://reviews.llvm.org/D65169 Cheers, Billy Moses -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190723/c29e167f/attachment.html>
Francis Visoiu Mistrih via llvm-dev
2019-Jul-25 00:29 UTC
[llvm-dev] [RFC] Optimization Remark for derived function / argument attributes
Hi Billy,> On Jul 23, 2019, at 4:46 PM, William Moses via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello all, > > During the compilation process, LLVM automatically derives various attributes about functions and values (for example that a pointer is nonnull, a function is constant, etc) that are used within a translation unit. > > I propose adding a pass to LLVM that allows front-ends to output derived attributes. Such a pass would be useful both for developers and end users to debug programs, either learning that an expected attribute was learned, or an unexpected attribute was learned (for example a pointer never being written to).This sounds like a good idea! Would adding new optimization remarks to passes that modify the attributes work? For example, we could emit an “analysis” remark in FunctionAttrs::setDoesNotRecurse.> > Evidently the following might not be the final interface, but one could imagine something like the following: > > $ ./clang foobar.c -g -Rannotations -O3 > foobar.c:2:1: remark: derived following attributes for function f: fn_attr("norecurse") fn_attr("nounwind") fn_attr("readonly") arg_attr(0, "nocapture") arg_attr(0, "readonly") [-Rannotations] > double f(double* a) { > > foobar.c: > > double f(double* a) { > return a[0]; > }If this is emitted as an analysis remark as suggested above, clang -Rpass-analysis=functionattrs could display the remarks in a similar way. This has also the advantage that it can be serialized to a file using -fsave-optimization-record without any extra work involved. Cheers, — Francis> > A work in progress patch implementing such an optimization remark is available here: https://reviews.llvm.org/D65169 <https://reviews.llvm.org/D65169> > > Cheers, > Billy Moses > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://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/20190724/41aac28b/attachment-0001.html>
William Moses via llvm-dev
2019-Jul-25 21:11 UTC
[llvm-dev] [RFC] Optimization Remark for derived function / argument attributes
Hi Francis, I'm wondering if it makes more sense to have a single pass to emit attributes rather than making sure that this is emitted in all passes that could modify arguments. If memory serves there's more than just FunctionAttrs. Cheers, Billy On Wed, Jul 24, 2019 at 5:32 PM Francis Visoiu Mistrih <francisvm at yahoo.com> wrote:> Hi Billy, > > On Jul 23, 2019, at 4:46 PM, William Moses via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hello all, > > During the compilation process, LLVM automatically derives various > attributes about functions and values (for example that a pointer is > nonnull, a function is constant, etc) that are used within a translation > unit. > > > I propose adding a pass to LLVM that allows front-ends to output derived > attributes. Such a pass would be useful both for developers and end users > to debug programs, either learning that an expected attribute was learned, > or an unexpected attribute was learned (for example a pointer never being > written to). > > > This sounds like a good idea! Would adding new optimization remarks to > passes that modify the attributes work? For example, we could emit an > “analysis” remark in FunctionAttrs::setDoesNotRecurse. > > > Evidently the following might not be the final interface, but one could > imagine something like the following: > > > $ ./clang foobar.c -g -Rannotations -O3 > foobar.c:2:1: remark: derived following attributes for function f: > fn_attr("norecurse") fn_attr("nounwind") fn_attr("readonly") arg_attr(0, > "nocapture") arg_attr(0, "readonly") [-Rannotations] > double f(double* a) { > > > foobar.c: > > > double f(double* a) { > return a[0]; > } > > > If this is emitted as an analysis remark as suggested above, clang > -Rpass-analysis=functionattrs could display the remarks in a similar way. > > This has also the advantage that it can be serialized to a file using > -fsave-optimization-record without any extra work involved. > > Cheers, > > — > Francis > > > A work in progress patch implementing such an optimization remark is > available here: https://reviews.llvm.org/D65169 > > > Cheers, > Billy Moses > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://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/20190725/a242b6f2/attachment.html>
Maybe Matching Threads
- [LLVMdev] why functionattrs doesn't add dependency of AliasAnalysis
- Test de Moses
- [ThinLTO] Making ThinLTO functions not fail hasExactDefinition (specifically preventing it from being derefined)
- [ThinLTO] Making ThinLTO functions not fail hasExactDefinition (specifically preventing it from being derefined)
- [LLVMdev] readnone