Re: [Open64-devel] Alias analysis problems

[Stephen H. C. <ste...@st...>]

My suggestion would be for the frontend to set the
flags conservatively: safe but suboptimal.  i.e. set addr-saved
whenever address is taken.  It is simple to do this in the FE.

Then if the inliner or ipa run, they can recalculate the
flags more accurately.

So you don't get best code unless you enable inliner/ipa,
but that seems a reasonable choice to me.

Rgds,
Stephen Clarke

shuxin yang wrote:
> I try to fix the problem this afternoon. It can be trigged either by the
> flags Stephen figured out or simply by "-O2".
> 
>  I manage to collect the addr-taken attribute for file static variable
> in the light-weight inliner.
> 
>   But what if this phase is turn off? In that case, should alias analyzer
> check this situation and say "may alias" for access with file static var
> and indirect variables. It is possible, however, pretty ugly.
> 
>   One option is to collect the attribute right before BE is enter. It is
> both costly and inconvenient due to. It is costly because BE should
> reload Pu local info twice. It is inconvenient because current 
> IR-reader/writer
> does not support read--use-discard--and-reload model.
> 
>  Another options is FE..
> 
>   In brief, my questions boil down to:
>   - Is standalone inliner the best phase to collect inter-procedural-SENSE
>      ST attribute?
>   -  If yes, what if that phase is turned off? which phase take over? FE or
>        BE (collect attribute right before BE) ?
> 
> Shuxin Yang
> 
> Stephen Huw CLARKE wrote:
>> We have observed a problem in the alias analysis of the open64
>> compiler.   This appears to be present in the latest
>> open64 3.0 release, as well as earlier releases.
>>
>> An example of the failure is the following:
>>
>> //// test.c
>> #include <stdio.h>
>>
>> static int y;
>> int foo (int *p1, int *p2)
>> {
>>    *p1 = 1;  *p2 = y;
>> }
>>
>> int main (void)
>> {
>>    int z;
>>    y = 2; z = 3;
>>    foo (&y, &z);
>>    printf ("y = %d (should be 1)\n", y);
>>    printf ("z = %d (should be 1)\n", z);
>>    return 0;
>> }
>> //// ends
>>
>> The problem is that, in the function foo,  the alias
>> analyzer does not compute an alias between *p1 and y,
>> so when the code is scheduled, the load from y may be
>> moved earlier than the store through p1.
>>
>> (To reproduce with open64-3.0, use
>> opencc -S -O3 -INLINE:none test.c -Wb,-ttopt:0x800
>> and observe incorrect alias information.)
>>
>> Now, it seems that the following alias rule should
>> compute this alias (from opt_alias_rule.h):
>>
>> *   A.4: (Indirect rule)
>> *     Indirect memory access cannot access variables that are not address
>> *     taken and saved.   See opt_alias_analysis.h for the definition
>>
>> However, y is not marked as address-saved, so this
>> rule does not find the alias.
>>
>> So I am wondering which part of the compiler should
>> mark y as address-saved?   When the address of a variable
>> is saved in another variable, then it is the front-end that
>> sets the address-saved attribute.  But in the above case (where
>> the address is taken and passed to another function), the
>> front-end does not set the address-saved attribute.
>> Is this simply an omission in the whirl translator?
>>
>> A possible complication is the existence of the distinct
>> address-passed attribute, but as far as we can see, this
>> is used as a local property of the current PU, i.e. it is not
>> necessarily correct if the address is passed by another PU.
>>
>> I think there are numerous ways to fix the problem I am seeing.
>> What I would like is some insight on the overall rationale
>> on how this is supposed to work in open64, to decide on the
>> best way to fix it.
>>
>> Regards,
>> Stephen Clarke.
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to 
>> share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Open64-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>>
>>   
> 
>