2011/11/18 Richard Guenther <richard.guent...@gmail.com>:
> On Thu, Nov 17, 2011 at 6:49 AM, Yuehai Du <duyue...@gmail.com> wrote:
>> 2011/11/17 Richard Guenther <richard.guent...@gmail.com>:
>>> On Wed, Nov 16, 2011 at 12:28 PM, Eric Botcazou <ebotca...@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
>>>>
>>>
>>
>
