[cfe-dev] no-alias generated as result of restrict function arguments

[Eli Friedman]

On Tue, Dec 11, 2012 at 6:12 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
>> From: "Chandler Carruth" <chandlerc at google.com>
>> To: "clang-dev Developers" <cfe-dev at cs.uiuc.edu>
>> Sent: Tuesday, December 11, 2012 5:17:43 AM
>> Subject: Re: [cfe-dev] no-alias generated as result of restrict function      arguments
>>
>>
>>
>>
>> On Sat, Dec 8, 2012 at 5:39 PM, Chandler Carruth <
>> chandlerc at google.com > wrote:
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Dec 8, 2012 at 5:09 PM, Joerg Sonnenberger <
>> joerg at britannica.bec.de > wrote:
>>
>>
>>
>>
>>
>> Hi all,
>> consider the following input:
>>
>> int y;
>>
>> void foo(int * restrict x)
>> {
>> if (x == &y)
>> (*x)++;
>> (*x)++;
>> }
>>
>> The clang codegen gives the argument of foo the noalias attribute and
>> GVN will optimise the condition to false.
>>
>> When discussing this on IRC, Chandler suggested that Clang shouldn't
>> be
>> creating the noalias attribute here, i.e. do alias interference. I'm
>> not
>> sure he is correct, but this is subtle enough to warrant some
>> discussion
>> before filling a PR.
>>
>>
>>
>> Sorry, I was wrong. On further consideration, I think Clang is
>> correct here.
>>
>>
>> 1) (*x) is an lvalue based on the pointer 'x' and is modified in the
>> function, so the restrict qualifier actually governs the set of
>> addresses viable...
>> 2) The expression 'y' is an lvalue expression AFAICT in the C99
>> standard, is not based on the pointer 'x', and thus cannot access
>> the same object which x points to.
>>
>>
>> Thus, clang is correct to optimize the condition to false I think...
>>
>> As Joerg pointed out in IRC, 'y' is an lvalue, but we do not use it
>> to access the object it designates, we only use it to compute the
>> address, and thus restrict should have no bearing on it. That would
>> in turn make Clang's optimization incorrect and also seems likely to
>> make 'noalias' essentially useless for modeling restrict. =/
>
> Does it really make it useless, or can we just not use it for computing icmp results on pointer values?

This.  I'm not sure why we're using noalias to optimize icmps in the
first place; we don't generally optimize icmps based on alias analysis
results, and the rules in LangRef don't appear to allow it.

-Eli