Skip to content

SLPVectorizer does not respect isFPVectorizationPotentiallyUnsafe() #106909

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nikic opened this issue Sep 1, 2024 · 2 comments
Closed

SLPVectorizer does not respect isFPVectorizationPotentiallyUnsafe() #106909

nikic opened this issue Sep 1, 2024 · 2 comments

Comments

@nikic
Copy link
Contributor

nikic commented Sep 1, 2024

SLPVectorizer currently incorrectly vectorizes FP instructions using ARM NEON (https://llvm.godbolt.org/z/c9866Yv13), which has non-IEEE compliant denormal flushing (#16648).

There is a isFPVectorizationPotentiallyUnsafe() TTI hook for this, which is checked by LoopVectorize, but not SLPVectorizer.

(Technically at fault here is the ARM backend for using NEON instructions for vector floating point ops, but LLVM currently handles this by preventing their implicit formation.)

@alexey-bataev
Copy link
Member

I cannot find where LoopVectorizer uses isFPVectorizationPotentiallyUnsafe. Could you point exact line of code? Searching through the LLVM code base provides only declarations of the function, but I cannot find a single reference

@nikic
Copy link
Contributor Author

nikic commented Sep 1, 2024

Sure, the call is here:

TTI->isFPVectorizationPotentiallyUnsafe()) {

See also the related code in

} else if (I.getType()->isFloatingPointTy() && (CI || I.isBinaryOp()) &&
!I.isFast()) {
LLVM_DEBUG(dbgs() << "LV: Found FP op with unsafe algebra.\n");
Hints->setPotentiallyUnsafe();

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants