craig.topper added a comment.
In D130311#3691029 <https://reviews.llvm.org/D130311#3691029>, @reames wrote:
> I'm not fluent on strict FP, so let me summarize my understanding. This is
> mostly so you can easily correct me if one my assumptions is wrong.
>
> - Under strict FP, clang will emit constrained fp intrinsics instead of
> normal floating point ops.
> - To my knowledge, clang will never emit an explicit vector constrained
> intrinsic.
operator +, -, *, / etc. on __attribute__((__vector_size__)) types will
generate vector constrained intrinsics.
> - The vectorizers (LV, SLP) don't appear to have any handling for constrained
> FP intrinsics. If it did, I'd expect it to have to ask about legality of the
> widened operation - the same way it does for e.g. a scatter/gather.
>
> So, my question is: why don't we support StrictFP when targeting a vector
> enabled platform? Don't we trivially support them by simply never using the
> vector forms?
================
Comment at: clang/lib/Basic/Targets/RISCV.cpp:286
+ // StrictFP support for vectors is incomplete.
+ if (ISAInfo->hasExtension("zve32x"))
+ HasStrictFP = false;
----------------
reames wrote:
> asb wrote:
> > There's also code in RISCVISAInfo.cpp that does `HasVector =
> > Exts.count("zve32x") != 0`. It's probably worth adding a helper
> > (`hasVInstructions`?) that encapsulates this, and use it from both places.
> It's not clear to me why this condition is specific to embedded vector
> variants. Do we have strict FP with +V? Either you need to fix a comment
> here, or the condition. One or the other.
V implies Zve64d implies Zve64f implies Zve32f and Zve64x. Zve32f implies
Zve32x. Zve32x is the root of the vector inheritance tree.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D130311/new/
https://reviews.llvm.org/D130311
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
