On Thu, Jan 30, 2014 at 1:51 PM, Paulo Matos <pma...@broadcom.com> wrote:
>> -----Original Message-----
>> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
>> Sent: 30 January 2014 12:43
>> To: Paulo Matos
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH] Vector mode addresses
>>
>> Paulo Matos <pma...@broadcom.com> writes:
>> > As a followup of the thread:
>> > http://gcc.gnu.org/ml/gcc/2014-01/msg00206.html
>> >
>> > consider the attached patch for submission. It fixes an ICE in case
>> > you try to use vector mode addresses and do not have it as mode
>> > dependent target hook. As discussed in the thread adding
>> > VECTOR_MODE_P to the target hook is a way to avoid ICE but as Richard
>> > S. mentioned it's more general to patch GCC up.
>>
>> But like I said, I think the VECTOR_MODE_P check should be in
>> mode_dependent_address_p (recog.c) rather than here. If vector
>> addresses are supported then they are mode-dependent, since the
>> number of elements in the address mode must match the number of
>> elements in the MEM mode.
>
>
> Have I misunderstood what you said:
> "If we do support vector addresses than I think the right fix is to
> check VECTOR_MODE_P there."
>
> From this I understood that you agreed that if vector_mode is supported for
> an address the check should be in simplify_rtx as it would prevent all target
> ports from adding the check to their hook, making it therefore more generic.
> You re-enforced this when you said:
> "I'd just prefer it
> to be in generic code because I think it's a target-independent rule."
>
> Apologies if I completely misunderstood you.
I'm curious on where you are seeing MEMs with a vector mode address.
What does that MEM even mean?
From the referenced mail:
new_rtx: (mem:V4SI (plus:V4SI (vec_concat:V4SI (vec_concat:V2SI
(const_int 0 [0])
(const_int 0 [0]))
(vec_concat:V2SI (const_int 0 [0])
(const_int 0 [0])))
that should be invalid and somehow lacks the subreg:DI. The bug is where
that got lost.
Richard.
>>
>> Thanks,
>> Richard
