Does LLVM's LoopVectorize pass re‑evaluate its cost model after profile‑guided optimization marks a function hot or cold?

Question

LLVM’s LoopVectorize pass decides whether to vectorize a loop based on a cost model that evaluates trip count, memory stride, alignment, and target‑specific vector width. The model is consulted during the pass’s execution, which typically runs before profile‑guided optimization (PGO) marks functions as hot or cold. After PGO, the optimizer may reorder or re‑run other passes, but it is unclear whether LoopVectorize is invoked again with the updated profile information or whether it retains its original cost‑model decision.
This raises the question of whether the vectorizer’s decision is stable across PGO iterations or if a hot/cold designation should trigger a re‑evaluation of vectorization profitability.
Does the LoopVectorize pass re‑run after PGO to incorporate the updated hot/cold flags? If it does not, what mechanisms exist to trigger a re‑evaluation of vectorization decisions when profile data changes? Are there existing passes or flags that force the vectorizer to reconsider its cost model after PGO?

Tasadduq Burney · Answer

Answer to the Core Question
The LoopVectorize pass evaluates its cost model once per loop when it runs. It uses whatever profile data is available at that moment, including the hot/cold flag that PGO emits for a function. If PGO marks a function as hot or cold before the pass runs, the cost model will incorporate that information and may change the vectorization decision. The pass does not perform a second cost‑model calculation after a function has already been marked; it simply relies on the profile data that is present when it executes.

Likely Explanation

PGO profiling generates .profraw files during a test run.
  These files contain execution counts and hot/cold markers for functions.
  When the compiler later runs with -fprofile-use, the LoopVectorize pass reads the profile data and uses the hot/cold flag in its trip‑count estimate.
  Because the pass runs only once per loop during a single optimization pipeline, it cannot “re‑evaluate” after the fact unless the entire pipeline is restarted.

Confirmed Facts (LLVM 18.x)

LoopVectorize consults the profile data during its single execution pass.
  Hot/cold marks are part of the profile data and influence the estimated execution count.
  Re‑running the pass after changing the profile (e.g., by generating a new .profraw) is the only way to see a different vectorization outcome.

How to Verify the Behavior on Your Build

Generate a profile:
    clang -fprofile-generate -O2 -S -emit-llvm your.c -o your.bc
./your_executable   # run to produce .profraw files
llvm-profdata merge -o merged.profdata *.profraw
  
  Compile with the profile and enable debug output for LoopVectorize:
    clang -fprofile-use=merged.profdata -mllvm -debug-only=loop-vectorize -O2 your.c -S -emit-llvm -o vectorized.bc
  
  Inspect the debug log for entries like:
    LoopVectorize: cost model for loop @0x...: tripCount=1234 hot=true
  
  To test hot vs. cold, add __attribute__((cold)) to a function or manipulate the profile to change its count, then repeat steps 1‑3. A different trip‑count estimate should appear in the log.

What to Do If You Need a Re‑evaluation

Regenerate the profile data (e.g., by running the instrumented binary again with different inputs).
  Re‑compile with -fprofile-use and let the optimization pipeline run fresh.
  Alternatively, run the compiler with -O3 or -fno-slp-vectorize to force different ordering of passes, but this does not guarantee a re‑evaluation of the cost model for the same loop.

Missing Detail Needed for Precise Guidance
Could you tell me which LLVM version you are using? The interaction between PGO and LoopVectorize has evolved, and the exact pass ordering can differ between releases.

Does LLVM's LoopVectorize pass re‑evaluate its cost model after profile‑guided optimization marks a function hot or cold?

1 answer

Answer to the Core Question

Likely Explanation

Confirmed Facts (LLVM 18.x)

How to Verify the Behavior on Your Build

What to Do If You Need a Re‑evaluation

Missing Detail Needed for Precise Guidance

Your perspective belongs here.

0 question comments