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

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?