https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111506
Robin Dapp <rdapp at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |joseph at codesourcery dot com
--- Comment #3 from Robin Dapp <rdapp at gcc dot gnu.org> ---
I just got back.
The problem with this is not -fno-trapping-math - it will vectorize just fine
with -ftrapping-math (and the vectorizer doesn't depend on it either). We also
already have tests for this in rvv/autovec/conversions.
However, not all int64 values can be represented in the intermediate type int32
which is why we don't vectorize unless the range of a[i] is know to be inside
int32's range. If I'm reading the C standard correctly it says such cases are
implementation-defined behavior and I'm not sure we should work around the
vectorizer by defining an expander that essentially hides the intermediate
type.
If that's an OK thing to do then I won't complain, though.
CC'ing jmyers and rsandi because they would know best.
>From what I can tell aarch64 also does not vectorize this and I wonder why
LLVM's behavior is dependent on -fno-trapping-math.
We have the same issue with the reversed conversion from _Float16 to int64. In
that case trapping math is relevant, though, but we could apply the same logic
as in this patch and circumvent it by an expander. To me this doesn't seem
right.
