[llvm-commits] [PATCH] basicaa - fix miscompilation of load from nocapture attribute (PR14045)

Dmitri Gribenko gribozavr at gmail.com
Fri Nov 2 11:45:00 PDT 2012


On Fri, Nov 2, 2012 at 8:29 PM, Richard Osborne <richard at xmos.com> wrote:
> On 02/11/12 17:52, Dmitri Gribenko wrote:
>>
>> Isn't there an issue with passing a nocapture pointer to a function
>> that does not give such a guarantee?  test3 could just store it to a
>> global.
>>
>> Dmitri
>>
> If test3 did store its argument to a global then that would violate the
> nocapture attribute and the behavior would be undefined. However if test3
> was implemented as follows:
>
> define void @test3(i32** %q, i32* %p) {
>   store i32* %p, i32** %q
>   ret void
> }
>
> Then the nocapture attribute isn't violated

Thank you, I did follow the original discussion.  My question was
about the validity of such an IR by itself: as you explained it, it
depends on *implementation* of 'test3'.  Wouldn't it be better to
disallow to pass 'nocapture' pointers to functions that don't give
such a guarantee?

But given your example, I see that it would overconstrain the IR.  The
point is that it is possible to write correct functions with
'nocapture' params using functions that don't have 'nocapture', but
that have some additional guarantees that we don't express directly in
the IR.

In my opinion this is a very subtle feature of 'nocapture' semantics
and it would be extremely useful to document this in the LangRef.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/



More information about the llvm-commits mailing list