Re: [PATCH] Vector mode addresses

[Richard Sandiford <rdsandiford at googlemail dot com>]

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

Right, in the context:

  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.

  http://gcc.gnu.org/ml/gcc/2014-01/msg00242.html

I.e. there == mode_dependent_address_p (defined in recog.c).

> 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."

No, I meant that I'd prefer it to be done in the target-independent
mode_dependent_address_p function.  This was in response to:

  Well, isn't it the case that a mem with vector mode is always mode
  dependent, in which case adding VECTOR_MODE_P to mode-dependent target
  hook would be enough making the patch not so useful?

  http://gcc.gnu.org/ml/gcc/2014-01/msg00248.html

where it sounded like you were instead going to add the check to your
target's TARGET_MODE_DEPENDENT_ADDRESS_P hook.  I don't think it makes
sense to defer the VECTOR_MODE_P check to the target hook since I don't
know how target-independent code could attach any meaning to something
like (mem:V4HI (reg:V4SI ...)) -> (mem:DI (reg:V4SI ...)).

Again, this is all on the basis that vector-mode addresses really
are supported.

Thanks,
Richard