aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
diff options
context:
space:
mode:
authorFlorian Hahn <flo@fhahn.com>2024-02-26 19:06:43 +0000
committerGitHub <noreply@github.com>2024-02-26 19:06:43 +0000
commit911055e34f2b1530d9900e23873e300b77ea8d96 (patch)
treeebe164ed9b68824dcafdf93e4a5e82187544a319 /llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
parent1865c7ea8561407626fe5489ae07647035413d7c (diff)
downloadllvm-911055e34f2b1530d9900e23873e300b77ea8d96.zip
llvm-911055e34f2b1530d9900e23873e300b77ea8d96.tar.gz
llvm-911055e34f2b1530d9900e23873e300b77ea8d96.tar.bz2
[VPlan] Consistently use (Part, 0) for first lane scalar values (#80271)
At the moment, some VPInstructions create only a single scalar value, but use VPTransformatState's 'vector' storage for this value. Those values are effectively uniform-per-VF (or in some cases uniform-across-VF-and-UF). Using the vector/per-part storage doesn't interact well with other recipes, that more accurately using (Part, Lane) to look up scalar values and prevents VPInstructions creating scalars from interacting with other recipes working with scalars. This PR tries to unify handling of scalars by using (Part, 0) for scalar values where only the first lane is demanded. This allows using VPInstructions with other recipes like VPScalarCastRecipe and is also needed when using VPInstructions in more cases otuside the vector loop region to generate scalars. Depends on https://github.com/llvm/llvm-project/pull/80269
Diffstat (limited to 'llvm/lib/ProfileData/Coverage/CoverageMapping.cpp')
0 files changed, 0 insertions, 0 deletions