This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix TARGET_MEM_REF and aliasing


On Sun, Nov 1, 2009 at 6:19 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
> Hi,
>
> up to recently the tree-ssa alias analysis engine balked at TARGET_MEM_REF.
>
> Now it doesn't entirely anymore:
>
> ?/* First defer to TBAA if possible. ?*/
> ?if (tbaa_p
> ? ? ?&& flag_strict_aliasing
> ? ? ?&& !alias_sets_conflict_p (ao_ref_alias_set (ref1),
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ao_ref_alias_set (ref2)))
> ? ?return false;
>
> ?/* If one reference is a TARGET_MEM_REF weird things are allowed. ?Still
> ? ? TBAA disambiguation based on the access type is possible, so bail
> ? ? out only after that check. ?*/
> ?if ((ref1->ref && TREE_CODE (ref1->ref) == TARGET_MEM_REF)
> ? ? ?|| (ref2->ref && TREE_CODE (ref2->ref) == TARGET_MEM_REF))
> ? ?return true;
>
> and this is problematic for non-addressable memory references because TBAA at
> the tree level doesn't compute the correct alias set, unlike at the RTL level.
>
> Testcase attached, compile on x86-64 at -O2. ?In cddce2:
>
> <bb 2>:
> ?D.2080[1]{lb: 1 sz: 4} = 1;
> ?D.2080[2]{lb: 1 sz: 4} = 1;
> ?D.2080[3]{lb: 1 sz: 4} = 1;
> ?D.2080[4]{lb: 1 sz: 4} = 1;
> ?a = D.2080;
> ?ivtmp.14_16 = (UNSIGNED_64) &a[1]{lb: 1 sz: 4};
> ?a.18_18 = (UNSIGNED_64) &a;
> ?D.2113_19 = a.18_18 + 16;
>
> <bb 3>:
> ?# ivtmp.14_14 = PHI <ivtmp.14_15(7), ivtmp.14_16(2)>
> ?D.2111_17 = (long int) ivtmp.14_14;
> ?D.2095_9 = MEM[index: D.2111_17];
>
> and in .dse2 the 4 initial stores are gone:
>
> <bb 2>:
> ?ivtmp.14_16 = (UNSIGNED_64) &a[1]{lb: 1 sz: 4};
> ?a.18_18 = (UNSIGNED_64) &a;
> ?D.2113_19 = a.18_18 + 16;
>
> <bb 3>:
> ?# ivtmp.14_14 = PHI <ivtmp.14_15(7), ivtmp.14_16(2)>
> ?D.2111_17 = (long int) ivtmp.14_14;
> ?D.2095_9 = MEM[index: D.2111_17];
>
>
> Hence the attached patch, tested on i586-suse-linux, OK for mainline?

I don't like it too much to add a new use for TMR_ORIGINAL, but
the patch is certainly correct.  We'll have to deal with the TMR_ORIGINAL
mess in 4.6.

Thus, ok.

Thanks,
Richard.

>
> 2009-11-01 ?Eric Botcazou ?<ebotcazou@adacore.com>
>
> ? ? ? ?* tree.def (TARGET_MEM_REF): Update comment.
> ? ? ? ?* alias.c (get_alias_set): Retrieve the original memory reference for
> ? ? ? ?a TARGET_MEM_REF before proceeding.
>
>
> 2009-11-01 ?Eric Botcazou ?<ebotcazou@adacore.com>
>
> ? ? ? ?* gnat.dg/opt5.adb: New test.
>
>
> --
> Eric Botcazou
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]