[llvm-commits] [PATCH] Try to figure out <size> argument in llvm.lifetime intrinsics

[Nick Lewycky]

Alexey Samsonov wrote:
> On Sat, Nov 10, 2012 at 3:55 AM, Nick Lewycky <nlewycky at google.com
> <mailto:nlewycky at google.com>> wrote:
>
>     On 9 November 2012 08:56, Alexey Samsonov <samsonov at google.com
>     <mailto:samsonov at google.com>> wrote:
>
>         Hi nicholas,
>
>         When optimizer inlines a function, it creates
>         llvm.lifetime.start/end intrinsics to mark
>         the lifetime of static allocations in inlined functions.
>         However, it doesn't set sizes of these
>         memory objects. This patch tries to guess them using the
>         information stored in AllocaInst.
>
>
>     Could you give me some context on why you want this?
>
>
> Yeah, sorry for not providing it. We think of using llvm.lifetime
> intrinsics in AddressSanitizer:
> http://code.google.com/p/address-sanitizer/issues/detail?id=83.
> For example, if we encounter llvm.lifetime.end(<size>, <ptr>) intrinsic
> in ASan function pass,
> we may mark the corresponding memory region as "unaddressable", so that
> any further access to
> it will produce an error report.
>
> As I can see, llvm.lifetime intrinsics are not that popular now, but
> probably we can emit them (in Clang)
> to find addressability issues with ASan and enable stack re-use with
> StackColoring machine function pass.
> void f() {
>    int *p;
>    {
>       int a = 0;
>       p = &a;
>    }
>    *p = 42; // Error!
> }
>
> That said, llvm.lifetime intrinsics are pretty useless for ASan if
> <size> argument is undefined :)
>
> Interestingly, I observed that sometimes <size> argument is not filled
> in when llvm.lifetime
> intrinsics are created (during function inlining), but is calculated in
> SROA pass. But...
> why don't we fill it in in the first place?

That makes sense. I wasn't bothering to fill it in because firstly it 
didn't have any users and would take time to fill in, and secondly 
because it doesn't seem to carry any information that you couldn't 
compute on-demand just as easily as having the inliner do it. Possibly 
even more easily if the optimizer has improved things post-inlining.

Let's get the inliner adding them. We might also want something else 
(like instcombine?) trying to replace unknown values with known ones.

Nick

>
>
>     Nick
>
>         http://llvm-reviews.chandlerc.com/D110
>
>
>
>
>
> --
> Alexey Samsonov, MSK
>