[Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974

--- Comment #15 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #14)
> (In reply to Vladimir Makarov from comment #13)
> > Sorry, I have no good knowledge of decompose_address.  The original author
> > is Richard Sandiford and it is even not in RA sources (it is in rtlanal.c).
> > 
> > I'd recommend to ask Richard may be he has some insights or just modify to
> > make it work in this case.  I can only say it is a sensitive code which can
> > affect a lot of targets if something is not done right. We had such problems
> > with this code in the past.
> 
> Ah, ok, CCing Richard.
> 
> Richard, can you comment on the findings in Comment #4?  Do we just need to
> add support for seeing a (plus (and: ....) (const int 8)) type of address or
> should we have never created anything like that in the first place or ???

Sorry for the slow reply, been a bit of a hectic week.

I think both fixes would be valid.  Like you say, the address
parsing code isn't yet ready to handle addresses that apply
an offset *before* the address "mutations".  That's because
no target has yet wanted to support such an address.  So as
things stand, the current address is not valid and shouldn't
have been created.

In some ways this is similar to creating an invalid highpart
subreg for the upper word of a doubleword vector hard register,
or a subreg that falls foul of some simplify_subreg_regno rule.
The RA has code to avoid doing that, see init_subregs_of_mode
and its users.  We could do something similar here for
REG_EQUIV MEMs.  One option would be to key off whether
strip_address_mutations is a no-op on the address.
Another would be to check whether each required sub-MEM
is valid for its mode and offset.  The latter would be
more elaborate but might produce better code in general,
not just for cases like this.

Like you say in comment 4, even the zero-offset half isn't
actually a valid address for PowerPC, so either of the two
options should give better code as well as fixing the bug.

On the other hand, the idea was always that address_info
and its users could be extended if new targets have new
requirements.  So if we want to make this operation valid
then that would be OK too.