[PATCH] Vector mode addresses
Thu Jan 30 17:10:00 GMT 2014
Paulo Matos <firstname.lastname@example.org> writes:
>> -----Original Message-----
>> From: Richard Sandiford [mailto:email@example.com]
>> Sent: 30 January 2014 12:43
>> To: Paulo Matos
>> Cc: firstname.lastname@example.org
>> Subject: Re: [PATCH] Vector mode addresses
>> Paulo Matos <email@example.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.
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?
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
More information about the Gcc-patches