[llvm-dev] Well-formed @llvm.lifetime.start and @llvm.lifetime.end intrinsics

Than McIntosh via llvm-dev llvm-dev at lists.llvm.org
Thu Mar 30 13:13:08 PDT 2017


I've updated the bug with my analysis.

Than


On Wed, Mar 29, 2017 at 12:39 PM, Reid Kleckner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I think lifetime start / end are poorly specified and need to be replaced.
> However, I've said that a lot, I haven't done anything about it myself, and
> people are probably tired of hearing me say it by now.
>
> I think Polly's transform is valid and this is a bug in stack coloring.
> Stack coloring needs to be able to cope with unmatched lifetime intrinsics.
>
> On Wed, Mar 29, 2017 at 4:39 AM, Michael Kruse via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi @all,
>>
>> I hit a problem with Polly-generated code which llvm.org/PR32251 . The
>> problem is how @llvm.lifetime.start is placed after Polly transformed
>> the code. Basically Polly transformed
>>
>>     llvm.lifetime.start(&var)
>>     [...]
>>     llvm.lifetime.end(&var)
>>
>> into
>>
>>     if (c) {
>>       llvm.lifetime.start(&var)
>>     }
>>     [...]
>>     llvm.lifetime.end(&var)
>>
>>
>> now the llvm.lifetime.end is not dominated by the corresponding
>> llvm.lifetime.start. As far as I understand the documentation [1] this
>> is a valid construction, meaning that the value of var is only
>> undefined before some point when c is true. I don't expect the
>> compiler to exploit this.
>>
>> However, this miscompiles since r270559 ("Rework/enhance stack
>> coloring data flow analysis", https://reviews.llvm.org/D18827)
>>
>> I modified Polly's code generator to produce
>>
>>     if (c) {
>>       llvm.lifetime.start(&var)
>>     } else {
>>       llvm.lifetime.start(&var)
>>     }
>>     [...]
>>     llvm.lifetime.end(&var)
>>
>> and it does not miscompile anymore. However, Polly is currently is not
>> able to compute the lifetime in the general case.
>>
>> Question: Is this a bug in the stack coloring algorithm or should this
>> be fixed in Polly?
>>
>>
>> Side question: Are there any invalid combinations of
>> llvm.lifetime.start/end such as
>>
>>     llvm.lifetime.end(&var)
>>     llvm.lifetime.start(&var)
>>
>> (my interpretation would be that var is always dead)? With invalid I
>> mean that the compiler does not need to handle this case.
>>
>> Regards,
>> Michael
>>
>> [1] http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170330/ddc7ab42/attachment.html>


More information about the llvm-dev mailing list