Results 1 to 4 of 4

Thread: Testing LLVM Clang 3.5's Code Generation Optimizations

  1. #1
    Join Date
    Jan 2007

    Default 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. #2
    Join Date
    Jun 2011


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

  3. #3
    Join Date
    Nov 2010
    Stockholm, Sweden


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

  4. #4
    Join Date
    Mar 2013


    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts