Prerequisites

• I am running the latest code. Mention the version if possible as well.

  I carefully followed the README.md.

  I searched using keywords relevant to my issue to make sure that I am creating a new issue that is not already open (or closed).

  I reviewed the Discussions, and have a new and useful enhancement to share.
  To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.

Feature Description

Hello,

I looked at the CMake code and noticed that one could add an additional CPU backend for Ivy Bridge/Piledriver.

From ggml/src/CMakeLists.txt at b7360:

...
        ggml_add_cpu_backend_variant(x64)
        ggml_add_cpu_backend_variant(sse42        SSE42)
        ggml_add_cpu_backend_variant(sandybridge  SSE42 AVX)
        ggml_add_cpu_backend_variant(haswell      SSE42 AVX F16C AVX2 BMI2 FMA)
        ggml_add_cpu_backend_variant(skylakex     SSE42 AVX F16C AVX2 BMI2 FMA AVX512)
        ggml_add_cpu_backend_variant(icelake      SSE42 AVX F16C AVX2 BMI2 FMA AVX512 AVX512_VBMI AVX512_VNNI)
        ggml_add_cpu_backend_variant(alderlake    SSE42 AVX F16C AVX2 BMI2 FMA AVX_VNNI)
...

Ivy Bridge and Piledriver support F16C but not AVX2. Support could be added with:

        ggml_add_cpu_backend_variant(ivybridge    SSE42 AVX F16C)

I looked at the code rest of the code, and conditions on __F16C__ but not __AVX2__ are few, but not zero. I'm not sure what the performance difference would be, and it would increase the size of a package with GGML_CPU_ALL_VARIANTS=ON.

Piledriver also seems to support FMA. It could have its own backend with:

        ggml_add_cpu_backend_variant(piledriver   SSE42 AVX F16C FMA)

I noticed there are some issues with MSVC around these two features specifically, but I think it's worth adding support just for GCC/Linux.

I would like to know if you would consider adding these additional backend(s), or if we could add comments in the CMakeLists.txt that these and other specific targets would not have dedicated backends. Thanks.

Motivation

I think it's worth adding the backend(s) for people who don't build their own custom binaries, and use packages built with GGML_CPU_ALL_VARIANTS=ON on older hardware. I think it supports Better packaging for llama.cpp to support downstream consumers. I have some Ivy Bridges with a "larger" amount of RAM I would like to try out llama.cpp on, and I build my own generic Linux packages.

Possible Implementation

I've already looked at the code, and so far I noticed that 2 lines need to be added to build an additional ivybridge backend. I built openSUSE, Fedora, and AlmaLinux packages with the additional backend successfully. I haven't tried to run the complete CI pipeline as suggested, so I didn't open an PR, and am looking for your feedback on the issue.