similar to: [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

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:

Hi Martin, I think this is another example of why we might consider having such function level attributes.. yes.  Chad On 4/4/2018 11:42 AM, Martin J. O'Riordan via llvm-dev wrote: > > 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

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)

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

On Thu, Apr 5, 2018 at 8:44 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 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

On Fri, Apr 6, 2018, 1:56 PM Peter Collingbourne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Apr 5, 2018 at 8:44 AM, via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > >> 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 : >>>

Wouldn’t implementing this proposal be a red herring? By this I mean, it is possible that throughout the optimization phases, there is an implied assumption that all functions are similarly optimized. An example would be under certain optimization flag, compiler changes calling convention of static functions. - Fariborz On Jun 17, 2013, at 8:58 AM, Andrea_DiBiagio at sn.scee.net wrote: >

On Wed, 9 Sep 2020 at 18:15, Min-Yih Hsu via llvm-dev < llvm-dev at lists.llvm.org> wrote: > David mentioned in D87337 that LLVM has used similar techniques on code > size (not sure what he was referencing, my guess will be something related > to hot-cold code splitting). > IIUC, it's just using optsize instead of optnone. The idea is that, if the code really doesn't

FYI David is referring to PGSO (profile-guided size optimization) as it exists directly under that name, see: https://reviews.llvm.org/D67120. And yeah using PGSO is selecting optsize while this change is selecting optnone. On 9/9/20, 10:58 AM, "llvm-dev on behalf of Tobias Hieta via llvm-dev" <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org> on

Hi, I previously made a proposal for adding a pragma for per-function optimization level control due to a number of requests from our customers (See http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958 for the previous discussion), however the discussion was inconclusive. Some of my colleagues recently had the opportunity to discuss the proposal with a number of people at and

On Wed, Sep 9, 2020 at 9:23 PM Wenlei He via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think calling PGSO size opt is probably a bit misleading though. It’s > more of an adaptive opt strategy, and it can improve performance too due to > better locality. We have something similar internally for selecting opt > level based on profile hotness too under AutoFDO. > >

Well, 'optnone' is already not identical to -O0, and given the nature of things, probably can't be; but I am persuaded that it's reasonable for it to honor the -fast-isel option as a debugging tactic. I'll take an AI to make this happen. Thanks, --paulr P.S. One nit, the "O0 + optnone" case should not have an asterisk, the FastISel flag is not manipulated if the opt

> > The other thing that might work, is having TargetMachine remember how > > the fast-isel option got set, and make OptLevelChanger do the right > > thing. But that seems like a hack to work around Mips not obeying the > > specified optimization level, honestly. > > I think we should do that as well. I don't think it's right that optnone > enables Fast

Dropping opt level should not lead to ABI changes. Otherwise you won't be able to mix-match O2 and O0 objects either. David On Mon, Jun 17, 2013 at 10:59 AM, jahanian <fjahanian at apple.com> wrote: > Wouldn’t implementing this proposal be a red herring? By this I mean, it is > possible that > throughout the optimization phases, there is an implied assumption that all >

Hello, We use PGO to optimize clang itself. I can see if I have time to give this patch some testing. Anything special to look out for except compile benchmark and time to build clang, do you expect any changes in code size? On Wed, Sep 9, 2020, 10:03 Renato Golin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, 9 Sep 2020 at 01:21, Min-Yih Hsu via llvm-dev < >

Andrea_DiBiagio at sn.scee.net wrote: > Hi, > > I previously made a proposal for adding a pragma for per-function > optimization level control due to a number of requests from our customers > (See http://comments.gmane.org/gmane.comp.compilers.clang.devel/28958 for > the previous discussion), however the discussion was inconclusive. Some > of my colleagues recently had the

On Jun 17, 2013, at 11:57 AM, Xinliang David Li <xinliangli at gmail.com> wrote: > Dropping opt level should not lead to ABI changes. Otherwise you won't > be able to mix-match O2 and O0 objects either. I was referring to “static functions”. Not that it happens, but something to consider. - Fariborz > > David > > On Mon, Jun 17, 2013 at 10:59 AM, jahanian

The driving goal of 'optnone' is to have an easy way for programmers to get an "-O0 like" debugging experience for selected functions, without making them build everything with –O0. To that end, we turn off as much optimization as we reasonably can, but in the context of a pipeline that is generally expecting optimizations to be enabled, in practice we can't exactly match –O0

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