similar to: [LLVMdev] Meaning of LLVM optimization levels

I'm not a LLVM or Clang developer, but I do spend a lot of time teasing software into working with the highest possible optimisation levels where it still works correctly. These guidelines are pretty good, but there are a few details worth considering. It needs to be possible to debug code at any optimisation level. It's acceptable for that to be harder at high optimisation levels, but

On 7 June 2013 13:53, Dallman, John <john.dallman at siemens.com> wrote: > It needs to be possible to debug code at any optimisation level. > Yes, I agree. But after O1, sequential execution is a big impediment for optimizations, and keeping the debug information valid after so many transformations might pose a big penalty on the passes (time & memory). That was the whole idea

Of course it's *possible*, in a fundamental sense. It's even pretty easy to get right in a compiler back end (in a conceptual sense). You have to touch a LOT of code, but all the changes are trivial. We did this at Tartan Labs back in the 90s. Done with only a bit of care, it makes debugging possible at any optimization level. The idea is to make the debug information reflect what the

> after O1, sequential execution is a big impediment for optimizations, and > keeping the debug information valid after so many transformations might > pose a big penalty on the passes (time & memory). That was the whole > idea of metadata being a second-class citizen. I'm afraid I don't know much about how debug information is expressed, so this idea may be nonsense. Is

On 7 June 2013 17:52, Dallman, John <john.dallman at siemens.com> wrote: > Is it possible for the debug information to mark all the instructions > that arise from a > > language statement as coming from that statement, even though the > instructions may > > be widely scattered? > I'm not aware Dwarf supports statements, but it does support line and column

GCC's optimize attribute should work fine (at least with trunk): __attribute__((optimize("O3","no-tree-pre"))) int foo( ...) { ... } will turn on -O3 for 'foo', but disable PRE pass for it. If you see any problems there, you should file a bug. Regarding Andrea's proposal -- the new #pragma can be useful (in rare cases when there is a compiler bug), the

On Thu, 15 Nov 2018 at 14:18, Sjoerd Meijer <Sjoerd.Meijer at arm.com> wrote: > > Ahhh, typo in my previous mail: > > > > when I noticed that -Os gives me Thumb on Cortex-A{8,9,17} > > > I wanted to say: > > > when I noticed that "GCC -Os" gives me Thumb on Cortex-A{8,9,17} > > Yes. Just to clarify my response. That particular linaro

Yes, exactly this: > Sure, none of the cortex-m cores support ARM mode. Try cortex-a{5,7,8,9,15,53} etc and you'll see it works. Sorry for being a bit vague and unclear here: yes, I should have said cortex-a{5,7,8,9,15,53}. I was just having a play with this native compiler: gcc-5 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609 when I noticed that -Os gives me Thumb on

> Although both cases would be nice and our users have expressed some > interest in both, the critical one is the second case of making sure that > some functions are never optimized is the most critical one. The major > use-case for this is for ease of debugging optimized builds. I have a similar usage case: I work on code that tends to show up optimiser bugs, possibly because it is

In reply to the question about what would be the common use case: > What is the common use case? Making sure some funtion is always > optimized or making sure it never optimized? If the second one, I > wonder if marking it cold would be a good enough approximation. Although both cases would be nice and our users have expressed some interest in both, the critical one is the second case

Hi, On 13.06.2013 20:15, Xinliang David Li wrote: > GCC's optimize attribute should work fine (at least with trunk): > > __attribute__((optimize("O3","no-tree-pre"))) int foo( ...) > { > ... > } > > will turn on -O3 for 'foo', but disable PRE pass for it. Indeed, the optimize attribute should do the job if you require optimization

My understanding is that whether a gcc toolchain defaults to ARM or Thumb is a configuration time decision by whomever builds the toolchain. The linaro arm-linux-gnueabihf toolchain I have defaults to -mthumb and that doesn't vary for -mcpu or any other command line option. I haven't got a gcc to hand that defaults to -marm so that I can test whether -mcpu=cortex-m3 will change that to

This has been an idea floating around in my head for a while and after several discussions with others it continues to hold up so I thought I would mail it out. Sorry for cross posting to both lists, but this is an issue that would significantly impact both LLVM and Clang. Essentially, LLVM provides canned optimization "levels" for frontends to re-use. This is nothing new. However, we

On Feb 26, 2011, at 6:12 PM, Jakob Stoklund Olesen wrote: >> >> All these patterns have one important downside. They are suboptimal if >> more than one store happens in a row. E.g. the 0 store is better >> expressed as xor followed by two register moves, if a register is >> available... This is most noticable when memset() gets inlined > > Note that

On Feb 26, 2011, at 4:50 PM, Joerg Sonnenberger wrote: > On Sun, Feb 27, 2011 at 01:29:25AM +0100, Joerg Sonnenberger wrote: >> +let Predicates = [OptForSize] in { >> +def : Pat<(store (i32 0), addr:$dst), (AND32mi8 addr:$dst, 0)>; >> +def : Pat<(store (i32 0), addr:$dst), (AND32mi8 addr:$dst, 0)>; >> +def : Pat<(store (i64 -1), addr:$dst), (OR64mi8

On 02/23/2013 04:28 AM, David Chisnall wrote: > Hi Reed, > > -Os could do with some love. It is more or less the same set of passes as -O2, but with a few things that are most likely to increase code size removed. We have had problems with it in the past for FreeBSD's bootloader. By tweaking the set of default passes added for -Os, I got the size down by about 20%, but I didn't

On 12 October 2016 at 14:26, Sebastian Pop <sebpop.llvm at gmail.com> wrote: > Correct me if I misunderstood: you would be ok changing the > reference output to exactly match the output of "-O0 -ffp-contract=off". No, that's not at all what I said. Matching identical outputs to FP tests makes no sense because there's *always* an error bar. The output of O0, O1, O2,

On Mon, Jun 26, 2017 at 5:04 AM, ORiordan, Martin <martin.oriordan at intel.com > wrote: > Thanks Sean and Silva. > > > > I guess what I was seeking was a URL that I could point (non-compiler) > people at, but I guess no such reference exists. What I can do if > reference bot the source manager and use ‘-mllvm -debug-pass=Structure’ > for each optimisation level,

Hello LLVM Community (specifically anyone working with ARM Cortex-M), While trying to compile the Newlib C library I found that Clang10 was generating slightly larger binaries than the libc from the prebuilt gcc-arm-none-eabi toolchain. I looked at a few specific functions (memcpy, strcpy, etc.) and noticed that LLVM does not tend to generate load/store instructions with a register offset (e.g.

At one of the BOFS during the llvm conference a few years back, one of the Apple managers stated in effect that their view of -Os was to get some modest savings but only if performance has near 0 impact. On 02/23/2013 09:45 AM, Reed Kotler wrote: > On 02/23/2013 04:28 AM, David Chisnall wrote: >> Hi Reed, >> >> -Os could do with some love. It is more or less the same set