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

[Daniel Berlin via llvm-dev]

I'm with Reid on this one.
Even the current specification is so underspecified as to mean pretty much
anything you like :)
But also like reid, i feel like this pops up every few months and we just
hatchet job it until we get something working again, and since i'm not
going to change that anytime soon,  so ...


On Wed, Mar 29, 2017 at 9:39 AM, 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/f8ef72cd/attachment-0001.html>