Dependence analysis with section anchors?

Marius Hillenbrand mhillen@linux.ibm.com
Tue Nov 24 11:13:20 GMT 2020


On 11/23/20 12:04 PM, Richard Biener wrote:
> On Mon, Nov 23, 2020 at 10:53 AM Marius Hillenbrand via Gcc
> <gcc@gcc.gnu.org> wrote:
>>
>> Hi,
>>
>> Digging into a test case failure with section anchors, I found
>> dependence analysis return false negatives, leading to bad optimization
>> by cse1. Two variables are synthetically constructed aliases. One is
>> addressed relative to the section anchor and the other using a symbol
>> ref, yet write_dependence_p() claims that they could not alias. I can
>> reproduce that miscompile on aarch64, ppc64, and s390x. How is
>> write_dependence_p() supposed to handle such cases with section anchors?
>>
>>
>> Example: (simplified version of gcc.c-torture/execute/alias-2.c)
>> int off; // causing nonzero offset of a to the section anchor
>> int a;
>> extern int b __attribute__ ((alias("a")));
>> /* ... */
>> int main()
>>   b=1;   <-- uses symbol_ref to b
>>   a=2;   <-- uses the section anchor + offset 4
>>   if (b!=2)
>>    __builtin_abort ();
>>   return 0;
>> }
>>
>> so write_dependence gets to compare the canonicalized addresses
>> (const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
>> (const_int 4 [0x4])))
>> and
>> (symbol_ref:DI ("b") [flags 0x602]  <var_decl b>)
>> and
>>
[...]
> 
> If the above is all we get to see then we have to give up when either
> of the address is based on a section anchor and we know the other
> one could possibly be refered through a section anchor.
> 
> In those cases we have to rely on MEM_EXPRs for disambiguation
> which, for the anchored address, is unfortunately lost?

Actually, both mem rtx have their MEM_EXPRs attached, in the cases I
looked at.

for example
(mem/c:SI (const:DI (plus:DI
   (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])


   (const_int 4 [0x4]))) [1 a+0 S4 A32])

We could add a check for cases where MEM_EXPRs are available and clearly
indicate aliasing or overlap. That check would happen before the other
methods that only look at partial information (e.g., base_alias_check,
memrefs_conflict_p) -- to catch such clear cases without the risk of
making the other checks more pessimistic.


> 
>> (see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 for the
>> initial report on aarch64 and my full example)
>>
>> Marius

-- 
Marius Hillenbrand
Linux on Z development
IBM Deutschland Research & Development GmbH
Vors. des Aufsichtsrats: Gregor Pillen / Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294


More information about the Gcc mailing list