On Fri, Sep 10, 2021 at 1:50 AM Segher Boessenkool
<seg...@kernel.crashing.org> wrote:
>
> 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 we _do_ already allow some of them :/ Like
/* ??? 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))
;
so for the special case where 'regsize' matches osize it would be
a bit-cast of a full register from int to float. But as written it also
allows (subreg:XF (reg:TI)) which will likely wreck havoc?
Similar for the omode == word_mode check which allows
(subreg:DI (reg:TF ..)). That is, the existing special-cases look
too broad to me - and they probably exist because when validate_subreg
rejects sth then we can't put it together later when expand split it
into two subregs and a pseudo ...
> > > 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.)
Sure, why not ...
Richard.
>
> Segher
