This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: a question about IVOPTS: find_interesting_uses_address
On Fri, Nov 18, 2011 at 2:07 AM, Yuehai Du <duyuehai@gmail.com> wrote:
> 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.
Yes, that's currently the only way. I'd rather eliminate this gap in expand
though and simply go the bitfield expansion way there.
Richard.
> --
> Yuehai
>
>>
>>> --
>>> Yuehai
>>>
>>>
>>>> Richard.
>>>>
>>>>> --
>>>>> Eric Botcazou
>>>>>
>>>>
>>>
>>
>