Re: a question about IVOPTS: find_interesting_uses_address

[Yuehai Du <duyuehai at gmail dot com>]

2011/11/18 Richard Guenther <richard.guenther@gmail.com>:
> On Thu, Nov 17, 2011 at 6:49 AM, Yuehai Du <duyuehai@gmail.com> wrote:
>> 2011/11/17 Richard Guenther <richard.guenther@gmail.com>:
>>> On Wed, Nov 16, 2011 at 12:28 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>>>>> Huh, IVOPTs should never cause a different size memory read. ?I wonder
>>>>> if the original issue would still reproduce with the fix reverted.
>>>>
>>>> The original issue was unaligned arrays in packed structures. ?I don't see what
>>>> could have changed since then.
>>>
>>> Ah, so it was expand being confused about the constructed access (not seeing
>>> a component-ref), thus the usual old issue we have there. ?There's indeed no
>>> trivial fix for this but to create the [TARGET_]MEM_REF with an explicitely
>>> unaligned type and hope that the target implements the movmisalign optab
>>> (the only case this explicit alignment is honored). ?And double-check the
>>> TARGET_MEM_REF expansion code properly duplicates the movmisalign
>>> path from the MEM_REF expander.
>>>
>>> I'd wish somebody fixed this path for non-movmisalign strict-align targets.
>>>
>>
>> ?I'm a little bit confused, and i don't know if i understand you correctly.
>> are you saying that we can remove those check in find_interesting_uses_address,
>> and handle this misalign memory reference as aligned memory reference,
>> just attach the
>> misalign information in type and let expander to choose correct
>> expansion dependent on
>> movmisalign optab icode ?
>
> Yes. ?But only if movmisalign is available.
>
>> ?In that case if Target don't support misalign memory access, the
>> result of IVOPTS will
>> be non-optimal since the cost of IV used in misalign memory access is
>> wrong, ?right?
>
> No, the cost of the IV is the same, independent on whether it is aligned or not.
>
> Richard.

  I got you,thanks.
  Would it be ok if i file a bug about this,like missed optimization
for misaligned
memory access in IVOPTS?

  and since the path for non-movmisalign strict-align targets don't
exist now, could i
add a condition in that check to avoid this. like:

       if (STRICT_ALIGNMENT && may_be_unaligned_p (base, step)
           && optab_handler (movmisalign_optab, mode) == CODE_FOR_nothing)
	goto fail;

  I don't know if it is appropriate to check optab in IVOPTS, sorry if
i go too far.

--
Yuehai

>
>> --
>> Yuehai
>>
>>
>>> Richard.
>>>
>>>> --
>>>> Eric Botcazou
>>>>
>>>
>>
>