[all-commits] [llvm/llvm-project] 13751c: [AArch64] Vectorise llvm.pow using vector intrinsi...

[David Sherwood via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 13751c87076b9fe1c235a951e75715a6761203a7
      https://github.com/llvm/llvm-project/commit/13751c87076b9fe1c235a951e75715a6761203a7
  Author: David Sherwood <david.sherwood at arm.com>
  Date:   2026-03-02 (Mon, 02 Mar 2026)

  Changed paths:
    M llvm/include/llvm/Analysis/VecFuncs.def
    M llvm/lib/Target/AArch64/AArch64TargetTransformInfo.cpp
    M llvm/test/CodeGen/AArch64/replace-with-veclib-armpl.ll
    M llvm/test/Transforms/LoopVectorize/AArch64/veclib-intrinsic-calls.ll

  Log Message:
  -----------
  [AArch64] Vectorise llvm.pow using vector intrinsic for ArmPL library (#183319)

When vectorising loops containing calls to the llvm.pow intrinsic we
currently end up with direct calls to the vector math library equivalent
of llvm.pow. This causes problems later on because we then miss out on
optimisations in the backend for things like

  pow(x, 0.25)
  pow(x, 0.75)
  etc.

There are a few different ways of trying to solve this, but I think the
cleanest way is to leave the call in the intrinsic form and then teach
the backend how to lower the FPOW DAG node to the vector math library
function. This is similar to what we already do for llvm.sincos/FSINCOS
today.

I've done this by removing the entries in Analysis/VecFuncs.def that map
the intrinsic to the vector math functions, whilst also teaching the
cost model that the vector intrinsic form of llvm.pow is cheap in the
presence of the library.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications