No announcement yet.

Testing LLVM Clang 3.5's Code Generation Optimizations

  • Filter
  • Time
  • Show
Clear All
new posts

  • Testing LLVM Clang 3.5's Code Generation Optimizations

    Phoronix: Testing LLVM Clang 3.5's Code Generation Optimizations

    For those curious about the performance of LLVM Clang in its current development form when testing the common code generation options for optimizing the performance (and in some cases size) of the resulting binaries, here's some fresh compiler benchmarks.

  • #2
    What's up with Scimark is it all hand tuned assembly or something?


    • #3
      Shouldn't you be running -march=native on all builds?


      • #4
        I don't think this tells us anything we didn't know, primarily that AVX2 support is not yet ready for primetime. I expect the AVX2 cost metrics are far from accurate, hence the occasional regression with -march=Haswell. The early Clang vectorization code took time to get its cost metrics right, and AVX2 is doubtless going through the same cycle.

        The other problem which specifically affects vectors (and thus -march=Haswell) is shuffles. There's been work to try to improve/consolidate shuffles, but it's not an easy problem. If you try to flatten out shuffles in one part of the compile pipeline, you generate a mess that can't be flattened out in a later part of the pipeline, so it's a constant battle to try to ensure that you're using the optimal number of shuffles. Once again there is a cost metric issue --- obviously at a certain point you're using so many shuffles to rearrange data that you're better off scalar.