The conversion script previously applied a complex saturation check
to all integer-to-float conversions using the _rtz and _rtn
rounding modes.
This logic is only necessary for `int` and `uint` to `float`
conversions, where precision loss near the maximum value can occur.
It was incorrectly applied to other types like `long` or `char`, and
to conversions targeting `double`.
This commit refines the conditional logic to ensure this specific
check is now applied only to the four intended cases:
- int -> float (_rtz/_rtn)
- uint -> float (_rtz/_rtn)
This commit ensures strict compliance with OpenCL 2.0 floating-point
conversion specifications:
* **RISCVISelLowering.cpp**:
- Map FRINT to RNE (round-to-nearest-even) instead of DYN (dynamic)
- Add proper FRM save/restore for vector floating-point operations
* **VentusInstrInfoV.td**:
- Enable VFCVT_RTZ_* instructions for truncation-based conversions
- Use RTZ (round-to-zero) mode for fp-to-int conversions to match
OpenCL spec
- Replace dynamic rounding with explicit RTZ for integer conversions
* **gen_convert.py**:
- Improve saturation handling in type conversions
- Add proper edge case handling for integer source saturation
- Distinguish between integer and float source conversion logic
* **Test Updates**:
- Update float.ll to expect RTZ instructions for fp-to-int conversions
- Add fround.ll test cases for ceil/floor/rint operations
These changes ensure that Ventus GPGPU backend produces OpenCL 2.0 compliant
floating-point conversion behavior, particularly for rounding modes and
saturation handling.
The rounding during type conversion uses multiple conversions, selecting
between them to try to discover if rounding occurred. This appears to
not have been tested, since it would generate code of the form:
float convert_float_rtp(char x)
{
float r = convert_float(x);
char y = convert_char(y);
[...]
}
which will access uninitialised data. The idea appears to have been to
have done a char -> float -> char roundtrip in order to discover the
rounding, so do this.
Discovered by inspection.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed By: jvesely
Differential Revision: https://reviews.llvm.org/D81999
The script's shebang wants Python 3, so we use FindPython3. The
original code didn't work when an unversioned python was not available.
This is explicitly allowed in PEP 394. ("Distributors may choose to set
the behavior of the python command as follows: python2, python3, not
provide python command, allow python to be configurable by an end user
or a system administrator.")
Also I think it's actually required, so let the configuration fail if we
can't find it.
Lastly remove the shebang, since the script is only run via interpreter
and doesn't have the executable bit set anyway.
Reviewed By: jvesely
Differential Revision: https://reviews.llvm.org/D88366
v3: change __builtin_nanf() to __builtin_nanf("")
This doesn't work yet, but it was agreed to commit as-is with the logic
that "broken" is better than "completely missing" and this should be
fixed in clang.
v2: use __builtin_inff() and also add nan/huge_val definitions
Signed-off-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 211065
wenhu1024
zhoujing