[HN Gopher] Clang's -O0 output: branch displacement and size inc...
       ___________________________________________________________________
        
       Clang's -O0 output: branch displacement and size increase
        
       Author : todsacerdoti
       Score  : 89 points
       Date   : 2024-04-27 01:04 UTC (21 hours ago)
        
 (HTM) web link (maskray.me)
 (TXT) w3m dump (maskray.me)
        
       | MaskRay wrote:
       | Thanks for posting:)
        
       | userbinator wrote:
       | This reminds me of fasm, the only assembler immediately coming to
       | mind that will do multi-pass branch optimisation _by default_.
       | Most other assemblers either choose the long form always unless
       | specified explicitly as  "jmps" or "jmp short" (and then complain
       | when the target turns out to be too far away), or the short form
       | only if the destination is known when it's encountered (backwards
       | jump).
       | 
       | I've long held the opinion that O0 on all the major compilers
       | should be considered more like an O-1 because of the glaring
       | stupidities it leaves in its output, which almost looks like it
       | was pessimising instead of not optimising.
       | 
       | This article is also only the 2nd time I've seen "relaxation"
       | used in this context. The first was
       | https://news.ycombinator.com/item?id=10219007 over 8 years ago.
        
         | ryukoposting wrote:
         | I'll second this. As a firmware dev, I almost never encounter
         | situations where O0 gets me anything in terms of asm
         | readability/debugging that O1 didn't already give me.
        
         | o11c wrote:
         | Despite the fact that you say "all the major compilers", GCC
         | and Clang make _very_ different decisions for each optimization
         | level.
         | 
         | In particular, GCC generates fairly debuggable code at all
         | optimization levels, so there is less motivation for -O0 in the
         | first place.
        
         | dataflow wrote:
         | Are you aware of -Og? It might be what you want.
        
           | usefulcat wrote:
           | I believe -Og is only meaningful for gcc. IIRC it's the same
           | as O1 for clang.
        
         | mati365 wrote:
         | Not the only. Mine assembler (and C compiler), written in
         | TypeScript, does the same despite being painfully slow and
         | useless.
         | 
         | https://github.com/Mati365/ts-c-compiler
        
         | mkup wrote:
         | NASM has an option (-Ox) to specify how many passes it should
         | take trying to optimize near jumps for short jumps. I usually
         | specify -O9.
        
         | pcwalton wrote:
         | > This reminds me of fasm, the only assembler immediately
         | coming to mind that will do multi-pass branch optimisation by
         | default. Most other assemblers either choose the long form
         | always unless specified explicitly as "jmps" or "jmp short"
         | (and then complain when the target turns out to be too far
         | away), or the short form only if the destination is known when
         | it's encountered (backwards jump).
         | 
         | Not true, gas will do the relaxation by default.
         | 
         | > This article is also only the 2nd time I've seen "relaxation"
         | used in this context.
         | 
         | It's been the standard term among toolchain developers for
         | quite a while. I remember seeing it all over the linker in 2007
         | when working on ARM stuff.
        
       | zhouzhouyi wrote:
       | When I debug a program, the first thing I do is to compile with
       | "-O0", very nice to remove "-mrelax-all" as the default for -O0,
       | because "-mrelax-all" increases both VM size and the file size.
        
       | ezekiel68 wrote:
       | > people generally care less about -O0 code size.
       | 
       | Right. A ~5% additional increase in debug artifact size is really
       | not a high tax.
        
       ___________________________________________________________________
       (page generated 2024-04-27 23:02 UTC)