via llvm-dev
2018-Apr-03 19:47 UTC
[llvm-dev] [RFC] Adding function attributes to represent codegen optimization level
All, A recent commit, D43040/r324557, changed the behavior of the gold plugin when compiling with LTO. The change now causes the codegen optimization level to default to CodeGenOpt::Default (i.e., -O2) rather than use the LTO optimization level. The argument was made that the LTO optimization level should control the amount of cross-module optimizations done by LTO, but it should not control the codegen optimization level; that should be based off of the optimization level used during the initial compilation phase (i.e., bitcode generation). Assuming the argument is reasonable (it make sense to me), I was hoping to solicit feedback on how to proceed. The suggestion in D43040/r324557 was to add function attributes to represent the compile-time optimization level (which also seems reasonable to me). As a first step, I've put together two patches: 1) an llvm patch that adds the function attributes to the LLVM IR and 2) a clang patch that attaches these attributes to each function based on the codegen optimization level. I then use the function level attributes to "reconstruct" to codegen optimization level used with LTO. Please understand this is very much a WIP and just a very small step towards a final solution. Here are the patches for reference: Clang: D45226 LLVM: D45225 Regards, Chad
David Blaikie via llvm-dev
2018-Apr-04 14:41 UTC
[llvm-dev] [RFC] Adding function attributes to represent codegen optimization level
On Tue, Apr 3, 2018 at 12:47 PM via llvm-dev <llvm-dev at lists.llvm.org> wrote:> All, > A recent commit, D43040/r324557, changed the behavior of the gold plugin > when compiling with LTO. The change now causes the codegen optimization > level to default to CodeGenOpt::Default (i.e., -O2) rather than use the > LTO optimization level. The argument was made that the LTO optimization > level should control the amount of cross-module optimizations done by > LTO, but it should not control the codegen optimization level; that > should be based off of the optimization level used during the initial > compilation phase (i.e., bitcode generation). >At least as I recall the discussion around optnone/optsize in the pass was that these were in some way special semantically distinct properties (optnone being "good for debugging" (or good for debugging compilers - what's the baseline behavior before optimizations are applied), optsize being "make this fit into something it wouldn't otherwise fit into") but that the gradiations of -ON didn't fit into this kind of model & wouldn't ever be implemented as function attributes. CC'd Chandler & Eric who I think had opinions/were involved in those previous discussions.> > Assuming the argument is reasonable (it make sense to me), I was hoping > to solicit feedback on how to proceed. The suggestion in D43040/r324557 > was to add function attributes to represent the compile-time > optimization level (which also seems reasonable to me). > > As a first step, I've put together two patches: 1) an llvm patch that > adds the function attributes to the LLVM IR and 2) a clang patch that > attaches these attributes to each function based on the codegen > optimization level. I then use the function level attributes to > "reconstruct" to codegen optimization level used with LTO. > > Please understand this is very much a WIP and just a very small step > towards a final solution. > > Here are the patches for reference: > Clang: D45226 > LLVM: D45225 > > Regards, > Chad > > > _______________________________________________ > 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/20180404/0f0b0ba3/attachment.html>
Martin J. O'Riordan via llvm-dev
2018-Apr-04 15:42 UTC
[llvm-dev] [RFC] Adding function attributes to represent codegen optimization level
Sorry, my reply “to all” left out LLVM-Dev From: Martin J. O'Riordan [mailto:MartinO at theheart.ie] Sent: 04 April 2018 16:41 To: 'David Blaikie' <dblaikie at gmail.com>; 'mcrosier at codeaurora.org' <mcrosier at codeaurora.org>; 'Chandler Carruth' <chandlerc at gmail.com>; 'Eric Christopher' <echristo at gmail.com> Subject: RE: [llvm-dev] [RFC] Adding function attributes to represent codegen optimization level Would implementing GCC’s ‘__attribute__((optimize(...)))’ help? I can’t find any good documentation for this attribute, but it seems that GCC supports this in two forms: __attribute__((optimize(2))) meaning optimise equivalent to ‘-O2’, and: __attribute_((optimize("fblah", "O1"))) meaning optimise with the provided discrete options. MartinO From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David Blaikie via llvm-dev Sent: 04 April 2018 15:41 To: mcrosier at codeaurora.org <mailto:mcrosier at codeaurora.org> ; Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com> >; Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com> > Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] [RFC] Adding function attributes to represent codegen optimization level On Tue, Apr 3, 2018 at 12:47 PM via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > wrote: All, A recent commit, D43040/r324557, changed the behavior of the gold plugin when compiling with LTO. The change now causes the codegen optimization level to default to CodeGenOpt::Default (i.e., -O2) rather than use the LTO optimization level. The argument was made that the LTO optimization level should control the amount of cross-module optimizations done by LTO, but it should not control the codegen optimization level; that should be based off of the optimization level used during the initial compilation phase (i.e., bitcode generation). At least as I recall the discussion around optnone/optsize in the pass was that these were in some way special semantically distinct properties (optnone being "good for debugging" (or good for debugging compilers - what's the baseline behavior before optimizations are applied), optsize being "make this fit into something it wouldn't otherwise fit into") but that the gradiations of -ON didn't fit into this kind of model & wouldn't ever be implemented as function attributes. CC'd Chandler & Eric who I think had opinions/were involved in those previous discussions. Assuming the argument is reasonable (it make sense to me), I was hoping to solicit feedback on how to proceed. The suggestion in D43040/r324557 was to add function attributes to represent the compile-time optimization level (which also seems reasonable to me). As a first step, I've put together two patches: 1) an llvm patch that adds the function attributes to the LLVM IR and 2) a clang patch that attaches these attributes to each function based on the codegen optimization level. I then use the function level attributes to "reconstruct" to codegen optimization level used with LTO. Please understand this is very much a WIP and just a very small step towards a final solution. Here are the patches for reference: Clang: D45226 LLVM: D45225 Regards, Chad _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org <mailto: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/20180404/4bcc3a2d/attachment.html>
Chad Rosier via llvm-dev
2018-Apr-04 15:44 UTC
[llvm-dev] [RFC] Adding function attributes to represent codegen optimization level
Thanks, David. I believe at least part of the discussion you're referring to can be found here: https://reviews.llvm.org/D28404 The issue I'm running into is that after r324557 the codegen optimization level during LTO defaults to CodeGenOpt::Default irrespective of what they user may have specified either during the initial compilation or during the LTO stage. This can have an impact on how the codegen pipeline is built (e.g., for AArch64 the SeparateConstOffsetFromGEPPass is only added to the pipeline with CodeGenOpt::Aggressive) or it may impact they way a function pass works (e.g., MachineBlockPlacement tail duplication is only run with CodeGenOpt::Aggressive). I'm particularly interested in fixing the latter case, which I think can be addressed by adding function attributes and then modifying the codegen passes to use the function attributes rather than the TargetPass optimization level. However, I'm open to alternative solutions/feedback. Chad On 4/4/2018 10:41 AM, David Blaikie wrote:> > > On Tue, Apr 3, 2018 at 12:47 PM via llvm-dev <llvm-dev at lists.llvm.org > <mailto:llvm-dev at lists.llvm.org>> wrote: > > All, > A recent commit, D43040/r324557, changed the behavior of the gold > plugin > when compiling with LTO. The change now causes the codegen > optimization > level to default to CodeGenOpt::Default (i.e., -O2) rather than > use the > LTO optimization level. The argument was made that the LTO > optimization > level should control the amount of cross-module optimizations done by > LTO, but it should not control the codegen optimization level; that > should be based off of the optimization level used during the initial > compilation phase (i.e., bitcode generation). > > > At least as I recall the discussion around optnone/optsize in the pass > was that these were in some way special semantically distinct > properties (optnone being "good for debugging" (or good for debugging > compilers - what's the baseline behavior before optimizations are > applied), optsize being "make this fit into something it wouldn't > otherwise fit into") but that the gradiations of -ON didn't fit into > this kind of model & wouldn't ever be implemented as function attributes. > > CC'd Chandler & Eric who I think had opinions/were involved in those > previous discussions. > > > Assuming the argument is reasonable (it make sense to me), I was > hoping > to solicit feedback on how to proceed. The suggestion in > D43040/r324557 > was to add function attributes to represent the compile-time > optimization level (which also seems reasonable to me). > > As a first step, I've put together two patches: 1) an llvm patch that > adds the function attributes to the LLVM IR and 2) a clang patch that > attaches these attributes to each function based on the codegen > optimization level. I then use the function level attributes to > "reconstruct" to codegen optimization level used with LTO. > > Please understand this is very much a WIP and just a very small step > towards a final solution. > > Here are the patches for reference: > Clang: D45226 > LLVM: D45225 > > Regards, > Chad > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto: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/20180404/99de14ae/attachment.html>
Mehdi AMINI via llvm-dev
2018-Apr-05 02:00 UTC
[llvm-dev] [RFC] Adding function attributes to represent codegen optimization level
Le mar. 3 avr. 2018 à 12:47, via llvm-dev <llvm-dev at lists.llvm.org> a écrit :> All, > A recent commit, D43040/r324557, changed the behavior of the gold plugin > when compiling with LTO. The change now causes the codegen optimization > level to default to CodeGenOpt::Default (i.e., -O2) rather than use the > LTO optimization level. The argument was made that the LTO optimization > level should control the amount of cross-module optimizations done by > LTO, but it should not control the codegen optimization level; that > should be based off of the optimization level used during the initial > compilation phase (i.e., bitcode generation). >I actually don't understand this clearly. Unless we're saying that we would change the IR optimization level either using the -OX flag during LTO (which is clumsy, because what is a "cross-module optimization" alone?), why would the `-OX` flag change the Codegen optimization level when passed to clang without LTO, but it wouldn't during LTO? Are we encoding O1/O2/O3 optimization level into function attributes and trying to honor these during the LTO IR optimization pipeline as well? Thanks, -- Mehdi> > Assuming the argument is reasonable (it make sense to me), I was hoping > to solicit feedback on how to proceed. The suggestion in D43040/r324557 > was to add function attributes to represent the compile-time > optimization level (which also seems reasonable to me). > > As a first step, I've put together two patches: 1) an llvm patch that > adds the function attributes to the LLVM IR and 2) a clang patch that > attaches these attributes to each function based on the codegen > optimization level. I then use the function level attributes to > "reconstruct" to codegen optimization level used with LTO. > > Please understand this is very much a WIP and just a very small step > towards a final solution. > > Here are the patches for reference: > Clang: D45226 > LLVM: D45225 > > Regards, > Chad > > > _______________________________________________ > 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/20180405/b9413d7c/attachment.html>
via llvm-dev
2018-Apr-05 15:44 UTC
[llvm-dev] [RFC] Adding function attributes to represent codegen optimization level
On 2018-04-04 22:00, Mehdi AMINI wrote:> Le mar. 3 avr. 2018 à 12:47, via llvm-dev <llvm-dev at lists.llvm.org> a > écrit : > >> All, >> A recent commit, D43040/r324557, changed the behavior of the gold >> plugin >> when compiling with LTO. The change now causes the codegen >> optimization >> level to default to CodeGenOpt::Default (i.e., -O2) rather than use >> the >> LTO optimization level. The argument was made that the LTO >> optimization >> level should control the amount of cross-module optimizations done >> by >> LTO, but it should not control the codegen optimization level; that >> should be based off of the optimization level used during the >> initial >> compilation phase (i.e., bitcode generation). > > I actually don't understand this clearly. > > Unless we're saying that we would change the IR optimization level > either using the -OX flag during LTO (which is clumsy, because what is > a "cross-module optimization" alone?), why would the `-OX` flag change > the Codegen optimization level when passed to clang without LTO, but > it wouldn't during LTO?I'm simply stating the argument made by Peter in r324557; this is not my opinion. Personally, I think it seems reasonable to allow the optimization flag used during the link step to control the codegen optimization level. However, this is no longer the case after r324557. FWIW, I would be very much on-board with reverting r324557 and then changing lld to mirror the behavior of the gold plugin, but I don't know if that's the consensus in the community.> Are we encoding O1/O2/O3 optimization level into function attributes > and trying to honor these during the LTO IR optimization pipeline as > well?No. The intent of these attributes are to control the codegen pipeline only. Of course this is all based on the assumption that using the optimization level used during bitcode generation should also be used with LTO in the codegen pipeline. I don't have a strong opinion either way. I just want codgen to respect the fact that I specified -O3 during both the bitcode generation and link steps, but that's not the case anymore. :) Chad> > Thanks, > > -- > Mehdi > >> Assuming the argument is reasonable (it make sense to me), I was >> hoping >> to solicit feedback on how to proceed. The suggestion in >> D43040/r324557 >> was to add function attributes to represent the compile-time >> optimization level (which also seems reasonable to me). >> >> As a first step, I've put together two patches: 1) an llvm patch >> that >> adds the function attributes to the LLVM IR and 2) a clang patch >> that >> attaches these attributes to each function based on the codegen >> optimization level. I then use the function level attributes to >> "reconstruct" to codegen optimization level used with LTO. >> >> Please understand this is very much a WIP and just a very small step >> towards a final solution. >> >> Here are the patches for reference: >> Clang: D45226 >> LLVM: D45225 >> >> Regards, >> Chad >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Possibly Parallel Threads
- [RFC] Adding function attributes to represent codegen optimization level
- [RFC] Adding function attributes to represent codegen optimization level
- [RFC] Adding function attributes to represent codegen optimization level
- [RFC] Adding function attributes to represent codegen optimization level
- [RFC] Adding function attributes to represent codegen optimization level