Announcement

Collapse
No announcement yet.

GCC 6/7 Gets A Performance-Sensitive Fix

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • GCC 6/7 Gets A Performance-Sensitive Fix

    Phoronix: GCC 6/7 Gets A Performance-Sensitive Fix

    A Phoronix reader pointed out a performance regression fix now available for GCC 6 and GCC 7 that could help some rather trivial C code perform much better...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Can someone explain what's happening at imulq and after that ?

    I thought imulq was one or two operand instruction...

    Comment


    • #3
      What they have to fix is that awful AT&T syntax. For god's sake!

      Comment


      • #4
        I figured that much, but thanks anyway.
        What baffled me is syntax of that imulq

        you have linked imul, but there is listed as imulq... aaah, I've read it the motorola way as "quick" whereas it was probably meant as "quadword" ( destination, i presume).
        So, it was meant as a second variant from your list, just that operands were listed from left/sources to right/dest, with comment about the value of that memory operand...

        Last edited by Brane215; 09 May 2017, 11:46 AM.

        Comment


        • #5
          Originally posted by wargames View Post
          What they have to fix is that awful AT&T syntax. For god's sake!
          I'm glad I'm not the only one who hates it! Having learned on Z80 (and picked up a bit of 8080 from the CP/M-80 debugger on the same platform - binary compatible but different assembly mnemonics) then graduated to x86 using a86/d86 (Intel syntax, instantly understandable to a Z80 programmer), I find reading the AT&T dialect a bit like trying to understand someone speaking perfectly good English with a near-impenetrable (for me) accent!

          Clever little trick, though - multiply by 2^38 / 200 then fast-divide by 2^38 using a bitshift. Much faster than the "obvious" way using an integer divide instruction. Oh, the joys of having loads of extra bits available.

          Comment


          • #6
            l presumably means longword, and q means quadword. Maybe d for doubleword was taken for 64 bit float, but in r13d the d means doubleword. I don't know what all the register arguments mean, but the instructions look like all 32 bit equivalents of the 64 bit new instructions and more complicated because it needs to fit in 32 bits. The sarl $31 thing is confusing, though, because it looks like a 32 bit right shift by 31 bits.

            Comment

            Working...
            X