[llvm-commits] [PATCH] Stack Coloring optimization

[Chandler Carruth]

On Wed, Sep 5, 2012 at 2:40 AM, Kostya Serebryany <kcc at google.com> wrote:

> +samsonov at google.com
>
> On Wed, Sep 5, 2012 at 1:12 AM, Chandler Carruth <chandlerc at google.com>wrote:
>
>> On Tue, Sep 4, 2012 at 4:41 PM, Chandler Carruth <chandlerc at google.com>wrote:
>>
>>> Hey Nadav, super excited about this.
>>>
>>> Recently, we tried to roll out some significant improvements to GCC's
>>> stack slot re-use, and discovered a really terrifying number of bugs in
>>> user code stemming from this. I would like to make sure that when using
>>> tools like ASan, this logic is disabled, and ASan can correctly detect code
>>> using an alloca after its lifetime has ended. Without this, it will be very
>>> hard to track down mis-compiles introduced here. Adding Kostya as I'm not
>>> familiar with the exact current state of ASan and lifetime of alloca
>>> instrumentation.
>>>
>>
>> Having read the discussion more carefully when we hit lots of user bugs
>> surrounding this, I have more information.
>>
>> The problem stems from re-use of locals after their lifetime ends. These
>> won't show up often until we teach Clang to emit the lifetime intrinsics
>> for those locals. Once we do, your pass will cause a very large amount of
>> code to blow up. It's a good thing too, as that code is *broken*.
>>
>> We need to teach ASan to use the lifetime markers to catch
>> use-after-lifetime-ends bugs first IMO, and *then* enable this pass and the
>> lifetime markers coming from Clang. That way we will already have the tools
>> to find these bugs quickly and accurately.
>>
>
> This is in our TODO, although, unfortunately, I am not sure when we will
> get to it.
> Perhaps in October.
> http://code.google.com/p/address-sanitizer/issues/detail?id=83&
>

I'm hoping that those interested in the optimization could potentially
contribute help toward this goal. =]


>
>
>>
>> We probably will also need to disable this particular optimization for
>> functions that have the ASan attribute set.
>>
>
> Hm. This is happening in the CodGen, i.e. after asan, right?
> asan merges all Alloca instructions into a single large Alloca, so under
> asan this optimization will be automatically disabled anyway. No?
>

Ah, nice. I had forgotten about that aspect of the instrumentation pass.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120905/4c5bc730/attachment.html>