diff options
author | Craig Topper <craig.topper@sifive.com> | 2024-08-14 14:51:05 -0700 |
---|---|---|
committer | Craig Topper <craig.topper@sifive.com> | 2024-08-14 15:18:10 -0700 |
commit | 4f7ce107de0c3ae0fb5748f98bc696b6eec7aad9 (patch) | |
tree | 3e233d8240f215a4f6a223c6ef0a1d8590300192 /clang/lib/Frontend/CompilerInvocation.cpp | |
parent | 48809fafbc083a2e4c03f70406b712ff18b42554 (diff) | |
download | llvm-4f7ce107de0c3ae0fb5748f98bc696b6eec7aad9.zip llvm-4f7ce107de0c3ae0fb5748f98bc696b6eec7aad9.tar.gz llvm-4f7ce107de0c3ae0fb5748f98bc696b6eec7aad9.tar.bz2 |
[RISCV] Don't combine (sext_inreg (fmv_x_anyexth X), i16) with Zhinx.
With Zfh and Zfhmin this combine creates a fmv_x_signexth node so we can
remember that the result is sign extended. This become a fmv.x.h
instruction which sign extends its result.
With Zhinx, fmv_x_signexth becomes a COPY_TO_REGCLASS. In order for
this to guarantee the result is properly sign extended we need all
producers of a GPRF16 register class to guarantee the rest of the
GPR is sign extended. I don't think we've done that. bitcasts from i16
to f16 definitely don't do it.
The safest thing to do is to not do this combine so the sign_extend_inreg
will emit a shift pair. This is also consistent with the code generated
for Zfinx on RV64, we don't assume the upper 32 bits are sign extended.
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions