Can you clarify what would be the semantic of this new attribute compared to optnone? Thanks, — Mehdi> On Jan 13, 2017, at 9:43 PM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I would prefer we introduce a new attribute for this purpose. I regularly use optnone for debugging/reduction purposes or when trying to understand the interaction of our pass pipeline. Having an attribute that tells the optimizer to ignore a function (more or less) is really useful, and I'd rather not loose that functionality. > > Philip > > > On 01/11/2017 08:34 AM, Robinson, Paul via llvm-dev wrote: >> In D28404, Mehdi wanted to use the 'optnone' attribute as a way to record >> "I was compiled with -O0" in the IR, because it seems like a good idea to >> remember that fact in an LTO compilation and there is no way to remember >> that fact currently. A couple of people felt it might be better to have >> this idea discussed on the dev list, where it might get better exposure, >> so I'm volunteering to get that discussion started. >> >> While 'optnone' does cause lots of optimizations to bypass a function, >> exactly matching -O0 was not the motivation and never a hard requirement. >> The implementation makes a distinct effort to get close to the behavior >> of -O0, but it's not an exact match and for the intended purpose (allowing >> a given function to be un-optimized to help debugging) it worked fine. >> >> Using 'optnone' to convey -O0 to LTO is something of a redefinition, or >> at least a re-purposing, of the attribute. To get there from here, I >> think we would need a couple of things to happen, separately from the >> minor grunt work of adding 'optnone' to function IR at -O0. >> >> 1) Update the LangRef definition of 'optnone' to reflect this intent. >> The current definition doesn't provide a motivation, and the description >> is (deliberately) a bit vague. If we want 'optnone' to intentionally >> match -O0, that should be tightened up. >> >> 2) Make a concerted effort to teach 'optnone' to targets. Currently >> I know the X86 target is aware of it, but I'm not so sure about others. >> >> 3) Take another look at what 'optnone' currently does *not* turn off, >> and see if there is something we can do about that. In some cases this >> will not be practical, and we may just have to live with that. >> >> (Okay, we need 3 things to happen.) >> >> I won't say this is blocking Mehdi's work, but it would remove a >> point of contention and allow the review to proceed more smoothly. >> --paulr >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Philip Reames via llvm-dev
2017-Jan-18 01:30 UTC
[llvm-dev] Redefining optnone to help LTO
My impression is that we *do* run some minimal cleanup passes at O0. Is that correct? If so, the biggest difference between what I believe the current optnone semantics to be and what you're proposing would be the behavior of those passes. Currently, optnone would direct those passes not to touch the function and skip execution. Under your proposal, those passes would run normally. I will freely admit that I'm not familiar with the O0 implementation, so it's possibly my assumptions are wrong. Philip On 01/13/2017 10:15 PM, Mehdi Amini wrote:> Can you clarify what would be the semantic of this new attribute compared to optnone? > > Thanks, > > — > Mehdi > >> On Jan 13, 2017, at 9:43 PM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> I would prefer we introduce a new attribute for this purpose. I regularly use optnone for debugging/reduction purposes or when trying to understand the interaction of our pass pipeline. Having an attribute that tells the optimizer to ignore a function (more or less) is really useful, and I'd rather not loose that functionality. >> >> Philip >> >> >> On 01/11/2017 08:34 AM, Robinson, Paul via llvm-dev wrote: >>> In D28404, Mehdi wanted to use the 'optnone' attribute as a way to record >>> "I was compiled with -O0" in the IR, because it seems like a good idea to >>> remember that fact in an LTO compilation and there is no way to remember >>> that fact currently. A couple of people felt it might be better to have >>> this idea discussed on the dev list, where it might get better exposure, >>> so I'm volunteering to get that discussion started. >>> >>> While 'optnone' does cause lots of optimizations to bypass a function, >>> exactly matching -O0 was not the motivation and never a hard requirement. >>> The implementation makes a distinct effort to get close to the behavior >>> of -O0, but it's not an exact match and for the intended purpose (allowing >>> a given function to be un-optimized to help debugging) it worked fine. >>> >>> Using 'optnone' to convey -O0 to LTO is something of a redefinition, or >>> at least a re-purposing, of the attribute. To get there from here, I >>> think we would need a couple of things to happen, separately from the >>> minor grunt work of adding 'optnone' to function IR at -O0. >>> >>> 1) Update the LangRef definition of 'optnone' to reflect this intent. >>> The current definition doesn't provide a motivation, and the description >>> is (deliberately) a bit vague. If we want 'optnone' to intentionally >>> match -O0, that should be tightened up. >>> >>> 2) Make a concerted effort to teach 'optnone' to targets. Currently >>> I know the X86 target is aware of it, but I'm not so sure about others. >>> >>> 3) Take another look at what 'optnone' currently does *not* turn off, >>> and see if there is something we can do about that. In some cases this >>> will not be practical, and we may just have to live with that. >>> >>> (Okay, we need 3 things to happen.) >>> >>> I won't say this is blocking Mehdi's work, but it would remove a >>> point of contention and allow the review to proceed more smoothly. >>> --paulr >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> On Jan 17, 2017, at 5:30 PM, Philip Reames <listmail at philipreames.com> wrote: > > My impression is that we *do* run some minimal cleanup passes at O0. Is that correct? >We only run the always_inliner (and forceattrs?), since it is needed for correctness AFAICT: $ echo "int main() {}" | clang -x c - -O0 -mllvm -debug-pass=Arguments -emit-llvm -c Pass Arguments: -tti -targetlibinfo -add-discriminators Pass Arguments: -tti -assumption-cache-tracker -profile-summary-info -targetlibinfo -forceattrs -basiccg -always-inline -barrier -write-bitcode> If so, the biggest difference between what I believe the current optnone semantics to be and what you're proposing would be the behavior of those passes. Currently, optnone would direct those passes not to touch the function and skip execution. Under your proposal, those passes would run normally. > > I will freely admit that I'm not familiar with the O0 implementation, so it's possibly my assumptions are wrong.I can miss some subtleties as well, so I’m happy to get other inputs on this! My intention is not to cause any disruption, I don’t of any non-required (from a semantic point-of-view) pass that we would want to intentionally run on optnone functions. Since you’re using the attribute on individual function you may have examples I haven’t thought of. — Mehdi> > Philip > > > On 01/13/2017 10:15 PM, Mehdi Amini wrote: >> Can you clarify what would be the semantic of this new attribute compared to optnone? >> >> Thanks, >> >> — >> Mehdi >> >>> On Jan 13, 2017, at 9:43 PM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> I would prefer we introduce a new attribute for this purpose. I regularly use optnone for debugging/reduction purposes or when trying to understand the interaction of our pass pipeline. Having an attribute that tells the optimizer to ignore a function (more or less) is really useful, and I'd rather not loose that functionality. >>> >>> Philip >>> >>> >>> On 01/11/2017 08:34 AM, Robinson, Paul via llvm-dev wrote: >>>> In D28404, Mehdi wanted to use the 'optnone' attribute as a way to record >>>> "I was compiled with -O0" in the IR, because it seems like a good idea to >>>> remember that fact in an LTO compilation and there is no way to remember >>>> that fact currently. A couple of people felt it might be better to have >>>> this idea discussed on the dev list, where it might get better exposure, >>>> so I'm volunteering to get that discussion started. >>>> >>>> While 'optnone' does cause lots of optimizations to bypass a function, >>>> exactly matching -O0 was not the motivation and never a hard requirement. >>>> The implementation makes a distinct effort to get close to the behavior >>>> of -O0, but it's not an exact match and for the intended purpose (allowing >>>> a given function to be un-optimized to help debugging) it worked fine. >>>> >>>> Using 'optnone' to convey -O0 to LTO is something of a redefinition, or >>>> at least a re-purposing, of the attribute. To get there from here, I >>>> think we would need a couple of things to happen, separately from the >>>> minor grunt work of adding 'optnone' to function IR at -O0. >>>> >>>> 1) Update the LangRef definition of 'optnone' to reflect this intent. >>>> The current definition doesn't provide a motivation, and the description >>>> is (deliberately) a bit vague. If we want 'optnone' to intentionally >>>> match -O0, that should be tightened up. >>>> >>>> 2) Make a concerted effort to teach 'optnone' to targets. Currently >>>> I know the X86 target is aware of it, but I'm not so sure about others. >>>> >>>> 3) Take another look at what 'optnone' currently does *not* turn off, >>>> and see if there is something we can do about that. In some cases this >>>> will not be practical, and we may just have to live with that. >>>> >>>> (Okay, we need 3 things to happen.) >>>> >>>> I won't say this is blocking Mehdi's work, but it would remove a >>>> point of contention and allow the review to proceed more smoothly. >>>> --paulr >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >