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

[Alexey Samsonov]

On Sat, Nov 10, 2012 at 3:55 AM, Nick Lewycky <nlewycky at google.com> wrote:

> On 9 November 2012 08:56, Alexey Samsonov <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?


>
> Nick
>
>
>> http://llvm-reviews.chandlerc.com/D110
>
>
>
>



-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121111/877c003e/attachment.html>