search for: optnone

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"...

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...

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 opt...

...ber 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 ISel even when it's been explicitly disabled. It should do > the same checks as addPassesToGenerateCode() does. Hm? What you're asking for is that "-O2" and "-O2 -fast-isel=none" are identical, unless you have an 'optnone' function. Do you...

Hello, I m trying to test individual O3 optimizations/ replicating O3 behavior on IR. I took unoptimized IR (O0), used disable-o0-optnone via (*clang -O0 -Xclang -disable-O0-optnone*). I read somewhere about *clang -O1 -Xclang -disable-O0-optnone,* so I also tested on this initial IR. I have observed by using individual optimizations, the performance (i.e time) is better when the base/initial IR is generated via *clang -O1 -Xcla...

On Wed, Jun 21, 2017 at 05:25:04PM -0700, Mehdi AMINI via llvm-dev wrote: > Hi Kuba, > > Try: > > __attribute__(optnone) > > See > https://clang.llvm.org/docs/AttributeReference.html#optnone-clang-optnone Actually, it should be enough to use: __attribute__((noinline)) void please_do_not_optimize_me_away(int arg1, void *arg2) { asm volatile("":::"memory"); } Creating a real barrier...

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...

...would be to allow users > to temporarily work-around optimization bugs in LLVM without having to > reduce the optimization level for the whole compilation unit, however we > do not consider this the most important use-case. > > Our suggestion for the name for this attribute is "optnone" which seems to > be in keeping with the existing "optsize" attribute, although it could > equally be called "noopt" or something else entirely. It would be exposed > to Clang users through __attribute__((optnone)) or [[optnone]]. > > I would like to discuss...

...would be to allow users > to temporarily work-around optimization bugs in LLVM without having to > reduce the optimization level for the whole compilation unit, however we > do not consider this the most important use-case. > > Our suggestion for the name for this attribute is "optnone" which seems to > be in keeping with the existing "optsize" attribute, although it could > equally be called "noopt" or something else entirely. It would be exposed > to Clang users through __attribute__((optnone)) or [[optnone]]. > > I would like to discuss...

...ers >> to temporarily work-around optimization bugs in LLVM without having to >> reduce the optimization level for the whole compilation unit, however we >> do not consider this the most important use-case. >> >> Our suggestion for the name for this attribute is "optnone" which seems to >> be in keeping with the existing "optsize" attribute, although it could >> equally be called "noopt" or something else entirely. It would be exposed >> to Clang users through __attribute__((optnone)) or [[optnone]]. >> >> I...

...this function: link <https://pastebin.com/rZHBm2iU>. I'm not 100% sure, but it seems like some pass within opt determines that a particular trap is guaranteed to occur on line 22, and so optimizes out the rest of the function, even though the pre-opt version of the function has the "optnone" attribute. Does this seem like intended behavior or some sort of bug? Is there any way to disable this behavior? Thanks! Best, Shishir On Tue, Jun 9, 2020 at 3:53 PM David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Jun 9, 2020 at 1:29 PM Shishir V Jessu <shishir.jessu at...

...ffect of this feature would be to allow users to temporarily work-around optimization bugs in LLVM without having to reduce the optimization level for the whole compilation unit, however we do not consider this the most important use-case. Our suggestion for the name for this attribute is "optnone" which seems to be in keeping with the existing "optsize" attribute, although it could equally be called "noopt" or something else entirely. It would be exposed to Clang users through __attribute__((optnone)) or [[optnone]]. I would like to discuss this proposal with t...

...ld be to allow users > to temporarily work-around optimization bugs in LLVM without having to > reduce the optimization level for the whole compilation unit, however we > do not consider this the most important use-case. > > Our suggestion for the name for this attribute is "optnone" which seems to > be in keeping with the existing "optsize" attribute, although it could > equally be called "noopt" or something else entirely. It would be exposed > to Clang users through __attribute__((optnone)) or [[optnone]]. > > I would like to dis...

On Thu, Jun 22, 2017 at 05:35:51PM +0000, David Blaikie wrote: > optnone should work, but really noinline should probably (Chandler: Can you > confirm: is it reasonable to model noinline as "no interprocedural analysis > across this function boundary" (so FunctionAttrs should do the same thing > for noinline as it does for optnone, for example? ie: no...

On x86_64-apple-darwin12, I am seeing regressions in the current llvm 3.4 release branch during 'make check'... Scanning dependencies of target check-llvm [100%] Running the LLVM regression tests FAIL: LLVM :: CodeGen/Generic/isel-optnone.ll (1362 of 9265) ******************** TEST 'LLVM :: CodeGen/Generic/isel-optnone.ll' FAILED ******************** Script: -- /sw/src/fink.build/llvm34-3.4-0/llvm-3.4/build/bin/./llc -debug < /sw/src/fink.build/llvm34-3.4-0/llvm-3.4/test/CodeGen/Generic/isel-optnone.ll -o /dev/null 2>&...

You can also add the -Xclang -disable-O0-optnone flag to your command line. This will disable the implicit optnone when compiling with O0. Cheers, Michael On Mon, Sep 18, 2017 at 7:27 AM +0200, "Craig Topper via llvm-dev" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: To prevent optnone from bein...

Hi David, By "dead" do you mean unreachable? My understanding was that the removal of dead code is simply another optimization, which should be disabled after adding "optnone" (and adding the function to llvm.used so the function doesn't later get deleted entirely). I am instrumenting certain basic blocks in an LLVM pass, and would like to compile a binary which structures things the same way the LLVM pass does, to analyze some behavior. I observe that my call...

...ly part of the program, CFI still requires to use LTO, IIUC. — Mehdi > > -- Sean Silva > > On Wed, Jan 11, 2017 at 8:34 AM, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> 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 discu...

...form LLVM 4.0 to 5.0. The code generator is written as an out-of-tree loadable module for opt. Till Clang 4.0 we were compiling the front-end code (annotated C++) using -O0. The generated bitcode was further processed using opt with our module loaded. In Clang 5.0 we see that using -O0 adds the optnone attribute to all functions, making it impossible to use any existing LLVM passes in our code generator. We also tried using - "clang -Xclang -load -Xclang <module>.so -mllvm <custom options>" , but this caused a segfault at llvm::legacy::FunctionPassManagerImpl::doInitial...

Paul, could you take a look at this? Maybe it would make more sense for the in-progress optnone work to be omitted from the release? -- Sean Silva On Thu, Nov 21, 2013 at 11:27 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > On x86_64-apple-darwin12, I am seeing regressions in the current > llvm 3.4 release branch during 'make check'... > > Scanning dep...