Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > One thought I had is whether we can "fix" validate_subreg to have less > "weird" allowed float-int > special cases. As said upthread I think that we either should allow > all of those, implying that > subregs work semantically as if there's subregs to same-sized integer > modes inbetween or > disallow them all and make sure we're actually doing that explicitely. > > For example > > /* ??? Similarly, e.g. with (subreg:DF (reg:TI)). Though store_bit_field > is the culprit here, and not the backends. */ > else if (known_ge (osize, regsize) && known_ge (isize, osize)) > ; > > I can't decipther rtl.text as to what the semantics of such a subreg is > given the docs hand-wave about WORDS_BIG_ENDIAN vs. > FLOAT_WORDS_BIG_ENDIAN but don't actually say what happens > when you mix those in a subreg. So maybe the above should > have explicitely have WORDS_BIG_ENDIAN == FLOAT_WORDS_BIG_ENDIAN. > > But then the world would be much simpler if subregs of non-same size > modes have explicit documentation for the mode kinds we have.
Yeah. Although validate_subreg was a good idea, some of the mode checks are IMO a failed experiment. The hope was that eventually we'd remove all those special exceptions once the culprit has been fixed. However, the code is over 16 years old at this point and those changes never happened. Nested subregs aren't a thing (thankfully) and one of the big disadvantages of the current validate_subreg mode-changing rules is that they aren't transitive. This can artificially require temporary pseudos for things that could be expressed directly as a single subreg. I'm not even sure we have to worry about WORDS_BIG_ENDIAN vs. FLOAT_WORDS_BIG_ENDIAN. The SUBREG_BYTE rules follow WORDS_BIG_ENDIAN for all modes, so its up to the generator of the subreg to diddle the SUBREG_BYTE if they want to use a different interpretation for floats. Thanks, Richard
