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

[Than McIntosh via llvm-dev]

OK, thanks for the additional info.

Sure, if you can send me a runnable test case, I can spend some time in the
debugger to learn more about how things are going wrong. It seems unlikely
that I would be able to identify the issue just looking at IR dumps or
source code, though.

Cheers, Than


On Wed, Mar 29, 2017 at 9:02 AM, Michael Kruse <llvmdev at meinersbur.de>
wrote:

> 2017-03-29 14:19 GMT+02:00 Than McIntosh <thanm at google.com>:
> > Hello Michael,
> >
> > Perhaps you could share a little more detail about your test case and the
> > specific failure mode. Without seeing the uses of the variable, it's
> hard to
> > tell how the new algorithm is going to behave.
>
> The test case that fails as mentioned in llvm.org/PR32251 is SPEC
> CPU's 2006 444.namd (version 1.1). In its main function there are
> several structs on the stack and annotated with lifetime markers.
> Polly does the previously mentioned transformation on one of those
> markers (which is not intended).
>
> Because the SPEC2006 is proprietary, I am not sure that I can share
> any code on the public mailing list. If I can convince you to look
> into it, I can send you source and the IR Polly is generating.
>
>
> > More specifically, when you say "miscompiles", I assume that this means
> that
> > StackColoring has overlapped two variables whose lifetimes are on fact
> not
> > disjoint after all?
>
> I diagnosed a miscompile because test-suite found that the program's
> output defers from the reference output. I did not look specifically
> what it does wrong. It did not miscompile before r270559 (git bisect).
>
>
> > The pattern you describe (where the lifetime start doesn't strictly
> dominate
> > the lifetime end) is referred to in the current stack coloring source
> code
> > as a "degenerate" lifetime; there is code that specifically looks for
> such
> > cases and treats them more conservatively than well-formed lifetimes
> (this
> > is described in the "Implementation Notes" comment in the source starting
> > around line 90). The key question however is where the uses of the
> variable
> > are relative to the lifetime start/end markers.
>
> I only overflew https://reviews.llvm.org/D18827 to find whether that
> case is mentioned, but couldn't find something.
>
> The degenerate case described moves the computation of the pointer
> before the LIFETIME_START marker, but the markers themselves are still
> (post-)dominating each other. As not being familiar with the code,
> this does not seem to be equivalent to my case.
>
>
> > For your side question (are there invalid ways to use lifetime
> start/end), I
> > don't think I really have a good answer there. What I have seen on my
> own is
> > that lifetime start/end markers tend to start out in more reasonable/sane
> > configurations, but then can be perturbed / rearranged during
> optimization,
> > resulting in orderings that don't always make sense (such as the case you
> > cite). My feeling is that this is OK, and that the stack coloring code
> > should be able to tolerate that sort of perturbation.
>
> Thanks for your thoughts.
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170329/8828f891/attachment.html>