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

Chandler Carruth chandlerc at google.com
Tue Dec 11 03:17:43 PST 2012


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. =/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121211/006b124c/attachment.html>


More information about the cfe-dev mailing list