Paulo Matos <pma...@broadcom.com> writes: >> -----Original Message----- >> From: Richard Sandiford [mailto:rdsandif...@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 <pma...@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
