[PATCH GCC]Resolve compilation time known alias checks in vectorizer

[Bin.Cheng]

On Fri, Jul 1, 2016 at 1:06 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Tue, Jun 28, 2016 at 8:18 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>> On Tue, Jun 14, 2016 at 1:57 PM, Richard Biener
>> <richard.guenther@gmail.com> wrote:
>>> On Mon, Jun 13, 2016 at 12:01 PM, Bin Cheng <Bin.Cheng@arm.com> wrote:
>>>> Hi,
>>>> GCC vectorizer generates many unnecessary runtime alias checks known at compilation time.  For some data-reference pairs, alias relation can be resolved at compilation time, in this case, we can simply skip the alias check.  For some other data-reference pairs, alias relation can be realized at compilation time, in this case, we should return false and simply skip vectorizing the loop.  For the second case, the corresponding loop is vectorized for nothing because the guard alias condition is bound to false anyway.  Vectorizing it not only wastes compilation time, but also slows down generated code because GCC fails to resolve these "false" alias check after vectorization.  Even in cases it can be resolved (by VRP), GCC fails to cleanup all the mess generated in loop versioning.
>>>> This looks like a common issue in spec2k6.  For example, in 434.zeusmp/ggen.f, there are three loops vectorized but never executed; in 464.h264ref, there are loops in which all runtime alias checks are resolved at compilation time thus loop versioning is proven unnecessary.  Statistic data also shows that about >100 loops are falsely vectorized currently in my build of spec2k6.
>>>>
>>>> This patch is based on https://gcc.gnu.org/ml/gcc-patches/2016-06/msg00399.html, bootstrap and test on x86_64 and AArch64 (ongoing), is it OK?
>>>
>>> This is PR71060 and PR65206?
>>>
>>> Rather than patching up vect_prune_runtime_alias_test_list to handle
>>> runtime known _not_ aliasing (does that happen?  for one of the
>>> testcases?) I'd patch vect_analyze_data_ref_dependence for that case.
>>> Yes, we can have cases where the runtime check generated
>>> is imprecise enough that it is proved to always alias, thus handling
>>> these cases seems fine (in which case handling the other is
>>> trivial).
>>>
>>> So I'm generally fine with the patch but please check the above PRs
>>> and eventually add testcases from them.
>> Hi,
>> The two PRs you mentioned is the case which is proved to always alias.
>> Before this patch, the loop is vectorized, alias check is generated
>> and then simplified into false, at last, the versioned loop gets
>> deleted.  With this patch, it proves always alias earlier and we won't
>> do the useless versioning any more.  And I checked spec, there are
>> quite a lot compile time no-alias cases.
>>
>> Here is the updated patch wrto your comments.  Is it OK?
>
> Ok.

Patch re-tested/applied on trunk as r238301.  As I mentioned
previously, gcc.dg/vect/vect-mask-store-move-1.c fails now because of
PR65206.

Thanks,
bin