llvm dev - Dec 2012 - [LLVMdev] [cfe-dev] no-alias generated as result of restrict function arguments

On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman
wrote:
> On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger
> > The original issue is that clang maps restrict on function arguments
to
> > NoAlias and that makes compares against the address of global
variables
> > false. Minimal test case:
> >
> > @y = external global i32
> >
> > define zeroext i1 @t(i32* noalias %x) nounwind uwtable readnone {
> > entry:
> >   %cmp = icmp eq i32* %x, @y
> >   ret i1 %cmp
> > }
> 
> The bug here isn't in clang's use of noalias or in
BasicAliasAnalysis'
> implementation of noalias; it's in the code that's optimizing the
> icmp.
I am just saying that the comments in BasicAliasAnalysis makes me wonder
if it has the same kind of problem.

Joerg

On Wed, Dec 12, 2012 at 2:45 PM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote:
>> On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger
>> > The original issue is that clang maps restrict on function
arguments to
>> > NoAlias and that makes compares against the address of global
variables
>> > false. Minimal test case:
>> >
>> > @y = external global i32
>> >
>> > define zeroext i1 @t(i32* noalias %x) nounwind uwtable readnone {
>> > entry:
>> >   %cmp = icmp eq i32* %x, @y
>> >   ret i1 %cmp
>> > }
>>
>> The bug here isn't in clang's use of noalias or in
BasicAliasAnalysis'
>> implementation of noalias; it's in the code that's optimizing
the
>> icmp.
>
> I am just saying that the comments in BasicAliasAnalysis makes me wonder
> if it has the same kind of problem.
And I am answering with an explanation of why the BasicAliasAnalysis
code in question does not have this same kind of problem. A NoAlias
response from AliasAnalysis isn't intended to imply inequality of
pointers, so there's no inherent problem with saying NoAlias for
pointers which can be equal. For the same reason, this is why using
AliasAnalysis information in instcombine/simplify to simplify pointer
comparisons is a bug.

Dan

On Thu, Dec 13, 2012 at 12:52 PM, Dan Gohman <dan433584 at gmail.com>
wrote:
> On Wed, Dec 12, 2012 at 2:45 PM, Joerg Sonnenberger
> <joerg at britannica.bec.de> wrote:
>> On Wed, Dec 12, 2012 at 01:59:55PM -0800, Dan Gohman wrote:
>>> On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger
>>> > The original issue is that clang maps restrict on function
arguments to
>>> > NoAlias and that makes compares against the address of global
variables
>>> > false. Minimal test case:
>>> >
>>> > @y = external global i32
>>> >
>>> > define zeroext i1 @t(i32* noalias %x) nounwind uwtable
readnone {
>>> > entry:
>>> >   %cmp = icmp eq i32* %x, @y
>>> >   ret i1 %cmp
>>> > }
>>>
>>> The bug here isn't in clang's use of noalias or in
BasicAliasAnalysis'
>>> implementation of noalias; it's in the code that's
optimizing the
>>> icmp.
>>
>> I am just saying that the comments in BasicAliasAnalysis makes me
wonder
>> if it has the same kind of problem.
>
> And I am answering with an explanation of why the BasicAliasAnalysis
> code in question does not have this same kind of problem. A NoAlias
> response from AliasAnalysis isn't intended to imply inequality of
> pointers, so there's no inherent problem with saying NoAlias for
> pointers which can be equal. For the same reason, this is why using
> AliasAnalysis information in instcombine/simplify to simplify pointer
> comparisons is a bug.
+1
This is precisely one of the differences between pointer analysis and
alias analysis.