On Thu, Sep 09, 2021 at 08:16:16AM +0200, Richard Biener wrote: > > I think we should (longer term) get rid of the overloaded meanings and > > uses of subregs. One fairly simple thing is to make a new rtx code > > "bit_cast" (or is there a nice short more traditional name for it?) > > But subreg _is_ bit_cast.
It is not. (subreg:M (reg:N) O) for O>0, little-endian, is not a bit_cast. It is taking a part of a register, or a single register from a multi-register thing. Paradoxicals are not bit-casts either. Subregs from or to (but not both) integer modes are generally bit_cast, yeah. > What is odd to me is that a "disallowed" subreg > like (subreg:SF (reg:TI ..) 0) magically becomes valid (in terms of > validate_subreg) if you rewrite it as (subreg:SF (subreg:SI (reg:TI ..) 0) 0). > Of course that's nested and invalid but just push the inner subreg to a > new pseudo and the thing becomes valid. Bingo. And many targets have strange rules for bit-strings in which modes can be used as bit-strings in which other modes, and at what offsets in which registers. Now perhaps none of that is optimal (I bet it isn't), but changing this without a transition plan simply does not work. > > But that is not the core problem we had here. The behaviour of the > > generic parts of the compiler was changed, without testing if that > > works on other targets but x86. That is an understandable mistake, it > > takes some experience to know where the morasses are. But this change > > should have been accompanied by testcases exercising the changed code. > > We would have clearly seen there are issues then, simply by watching > > gcc-testresults@ (and/or maintainers are on top of the test results > > anyway). Also, if there were testcases for this, we could have some > > confidence that a change in this area is robust. > > Well, that only works if some maintainers that are familiar enough > with all this chime in ;) Not really. It works always. And it works way better than the pandemonium we now have with broken targets left and right. With testcases anyone can see if any specific target is broken here. > It's stage1 so it's understandable that some > people (like me ...) are tyring to help people making progress even > if that involves trying to decipher 30 years of GCC history in this > area (without much success in the end as we see) ;) Yeah :-) And my thanks to you and everyone involved for tackling this problematic part of GCC, which has been neglected and patched over for way too long. But from that same history it follows that anything you do not super carefully (with testing everywhere) will cause some serious problems. And nonse of these are easy to fix at all -- there is a *reason* targets did this nastiness. > > p.s. Very unrelated... Should we have __builtin_bit_cast for C as well? > > Is there any reason this could not work? Still interested in this btw :-) (And still very unrelated.) Segher
