Re: [PATCH] Builtins handling in IVOPT

["Bin.Cheng" <amker dot cheng at gmail dot com>]

On Sat, Nov 23, 2013 at 4:05 PM, Wei Mi <wmi@google.com> wrote:
> On Thu, Nov 21, 2013 at 12:19 AM, Zdenek Dvorak
> <rakdver@iuuk.mff.cuni.cz> wrote:
>> Hi,
>>
>>> This patch works on the intrinsic calls handling issue in IVOPT mentioned here:
>>> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01295.html
>>>
>>> In find_interesting_uses_stmt, it changes
>>>
>>> arg = expr
>>> __builtin_xxx (arg)
>>>
>>> to
>>>
>>> arg = expr;
>>> tmp = addr_expr (mem_ref(arg));
>>> __builtin_xxx (tmp, ...)
>>
>> this looks a bit confusing (and wasteful) to me. It would make more sense to
>> just record the argument as USE_ADDRESS and do the rewriting in rewrite_use_address.
>>
>> Zdenek
>
> I updated the patch. The gimple changing part is now moved to
> rewrite_use_address. Add support for plain address expr in addition to
> reference expr in find_interesting_uses_address.
>
> bootstrap and testing is going on.
>
> 2013-11-22  Wei Mi  <wmi@google.com>
>
>         * expr.c (expand_expr_addr_expr_1): Not to split TMR.
>         (expand_expr_real_1): Ditto.
>         * targhooks.c (default_builtin_has_mem_ref_p): Default
>         builtin.
>         * tree-ssa-loop-ivopts.c (builtin_has_mem_ref_p): New function.
>         (rewrite_use_address): Add TMR for builtin.
>         (find_interesting_uses_stmt): Special handling of builtins.
>         * gimple-expr.c (is_gimple_address): Add handling of TMR.
>         * gimple-expr.h (is_gimple_addressable): Ditto.
>         * config/i386/i386.c (ix86_builtin_has_mem_ref_p): New target hook.
>         (ix86_atomic_assign_expand_fenv): Ditto.
>         (ix86_expand_special_args_builtin): Special handling of TMR for
>         builtin.
>         * target.def (builtin_has_mem_ref_p): New hook.
>         * doc/tm.texi.in: Ditto.
>         * doc/tm.texi: Generated.
Hi,
I have no right to approve but do have one comment.  One day this
optimization may be applied for a target which supports auto-increment
addressing mode, I think we need to handle these address iv uses
differently with original REAL ones (from memory access), and don't
create IV_{BEFORE,AFTER} candidates for them in function
add_candidate.  The number of candidates are already kind of bloated
with auto-increment now.

Thanks,
bin

>
> 2013-11-22  Wei Mi  <wmi@google.com>
>
>         * gcc.dg/tree-ssa/ivopt_5.c: New test.
>
-- 
Best Regards.