Re: ICE in trunk due to MEM with address in vector mode

[Richard Sandiford <rdsandiford at googlemail dot com>]

Paulo Matos <pmatos@broadcom.com> writes:
>> -----Original Message-----
>> From: Richard Sandiford [mailto:rdsandiford@googlemail.com]
>> Sent: 24 January 2014 10:46
>> To: Paulo Matos
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: ICE in trunk due to MEM with address in vector mode
>> 
>> Paulo Matos <pmatos@broadcom.com> writes:
>> > Hello,
>> >
>> > I have found a strange case of an ICE due to a MEM with an address
>> > with vector mode.
>> 
>> AFAIK that isn't supported.  Addresses are assumed to be MODE_INT or
>> MODE_PARTIAL_INT.  Hopefully someone will correct me if this has changed
>> without me noticing it.
>> 
>> Is this for some kind of gather load?  I think an address like that
>> would have to be mode-dependent anyway, since the number of units
>> in the MEM mode and the address mode would need to match.
>>
>
> Thanks for your comment.
> We have an instruction that loads two 32 bit values into a lower and
> upper parts of a 64bit register using a base register and a 64 bit
> register used as a double index.
> So,
> r1 <- [r0, r2] 
> means:
> low(r1) = [r0 + low(r2)]
> high(r1) = [r0 + high(r2)]
>
> In this case we use vector addresses. If it is indeed not allowed then I
> need another solution. Used to work well in 4.8 and before. In trunk it
> breaks, but works with the patch I included before.

Just in case: the point I was trying to make in the second paragraph
was that the code in the patch only triggers (as you say) because the
address isn't seen as mode-dependent.  But this kind of address does
look mode-dependent to me, since it only works for MEM modes that have
the same number of elements as the index vector.  So this does sound
like a case where mode_dependent_address_p ought to return true.

If we do support vector addresses than I think the right fix is to
check VECTOR_MODE_P there.

Thanks,
Richard