On Thu, Aug 26, 2021 at 11:06 AM Richard Sandiford <richard.sandif...@arm.com> wrote: > > 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.
And that's what the proposed patch does (add same-mode size integer mode punning intermediate subregs). So if that's not supposed to be necessary then why restrict subregs at all? I mean you seem to imply that the semantics would be clear and well-defined (to you - not to me). The only thing is that of course not all subregs are "implemented" by a target (or can be, w/o spilling). Which means - we should adjust validate_subreg with another special-case or rather generalize the existing ones to an overall set that makes more sense? Richard. > 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
