On Tue, Sep 10, 2024 at 5:25 PM Jeff Law <jeffreya...@gmail.com> wrote: > > > > On 9/8/24 3:28 PM, Christoph Müllner wrote: > > On Sat, Sep 7, 2024 at 7:08 PM Jeff Law <jeffreya...@gmail.com> wrote: > >> > >> > >> > >> On 9/6/24 5:32 AM, Jin Ma wrote: > >>> In the process of DF to SI, we generally use "unsigned_fix" rather than > >>> "truncate" for conversion. Although this has no effect in general, > >>> unexpected ICE often occurs when precise semantic analysis is required. > >>> > >>> gcc/ChangeLog: > >>> > >>> * config/riscv/riscv.md: Change "truncate" to "unsigned_fix" for > >>> the Zfa extension on rv32. > >>> > >>> gcc/testsuite/ChangeLog: > >>> > >>> * gcc.target/riscv/zfa-fmovh-fmovp-bug.c: New test. > >> This doesn't look correct. > >> > >> fmv.x.w just moves the bits from one place to another, no conversion. > >> > >> So I don't see how the original pattern was correct. Using truncate on > >> an FP mode source isn't defined. But I also don't think the updated > >> pattern is correct either. > >> jeff > > > > Having matching pattern for these Zfa moves seems pointless because > > the optimization that utilizes the instructions in > > riscv_split_doubleword_move() uses: > > gen_movdfsisi3_rv32(), gen_movsidf2_low_rv32() and gen_movsidf2_high_rv32(). > > In the XTheadFmv pattern, we use unspec, so the pattern won't match. > > I think this should be done for Zfa as well. > But if the generated code is just moving bits, why can't we use the > standard movXX patterns for the data movement? Clearly there's > something about this that I'm missing.
This is a special case for rv32 + D, where we have SI, SF and DF, but no DI. This raises the question of how to model a 2x 32-bit register <-> DF register transfer. This is currently done using movdf_hardfloat_rv32, which could either go through memory (no Zfa), or create an "artificial" 64-bit move using the constraint "zmvr", which will later be picked up by the doubleword-move splitter, which converts the move into a Zfa move via riscv_split_doubleword_move().
