[llvm-commits] [llvm] r166267 - in /llvm/trunk: lib/Transforms/Instrumentation/AddressSanitizer.cpp test/Instrumentation/AddressSanitizer/basic.ll

Kostya Serebryany kcc at google.com
Fri Oct 19 00:12:03 PDT 2012


On Fri, Oct 19, 2012 at 10:32 AM, Chandler Carruth <chandlerc at google.com>wrote:

> On Thu, Oct 18, 2012 at 11:20 PM, Kostya Serebryany <kcc at google.com>wrote:
>
>> Author: kcc
>> Date: Fri Oct 19 01:20:53 2012
>> New Revision: 166267
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=166267&view=rev
>> Log:
>> [asan] make sure asan erases old unused allocas after it created a new
>> one. This became important after the recent move from ModulePass to
>> FunctionPass because no cleanup is happening after asan pass any more.
>>
>
> We should almost certainly run a few passes after asan. instcombine, gvn,
> instcombine, and simplifycfg would be my baseline to experiment with (and
> compare compile times of). GVN is likely the most expensive, and it might
> be acceptable to just do instcombine + simplifycfg.
>

We run a whole bunch of optimization passes after the Msan pass. It indeed
helps.
I tried doing that after Asan and got these SPEC results:

 spec                            no-opt        opt             diff (<1
means improvement)
       400.perlbench,      1026.00,      1052.00,         1.03
           401.bzip2,       876.00,       864.00,         0.99
             403.gcc,       538.00,       536.00,         1.00
             429.mcf,       593.00,       588.00,         0.99
           445.gobmk,       838.00,       843.00,         1.01
           456.hmmer,      1271.00,      1292.00,         1.02
           458.sjeng,       921.00,       891.00,         0.97
      462.libquantum,       496.00,       492.00,         0.99
         464.h264ref,      1150.00,      1147.00,         1.00
         471.omnetpp,       592.00,       587.00,         0.99
           473.astar,       680.00,       695.00,         1.02
       483.xalancbmk,       570.00,       570.00,         1.00
            433.milc,       683.00,       664.00,         0.97
            444.namd,       635.00,       635.00,         1.00
          447.dealII,       625.00,       626.00,         1.00
          450.soplex,       360.00,       357.00,         0.99
          453.povray,       422.00,       417.00,         0.99
             470.lbm,       389.00,       415.00,         1.07
         482.sphinx3,       931.00,       925.00,         0.99

It deserves more tuning and experiments, but I don't expect a large gain
here.

--kcc


>
> Don't get me wrong, this change is still a good idea -- you can eliminate
> these allocas more cheaply than anything else.
>
>
>>
>> Modified:
>>     llvm/trunk/lib/Transforms/Instrumentation/AddressSanitizer.cpp
>>     llvm/trunk/test/Instrumentation/AddressSanitizer/basic.ll
>>
>> Modified: llvm/trunk/lib/Transforms/Instrumentation/AddressSanitizer.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Instrumentation/AddressSanitizer.cpp?rev=166267&r1=166266&r2=166267&view=diff
>>
>> ==============================================================================
>> --- llvm/trunk/lib/Transforms/Instrumentation/AddressSanitizer.cpp
>> (original)
>> +++ llvm/trunk/lib/Transforms/Instrumentation/AddressSanitizer.cpp Fri
>> Oct 19 01:20:53 2012
>> @@ -1148,6 +1148,10 @@
>>      }
>>    }
>>
>> +  // We are done. Remove the old unused alloca instructions.
>> +  for (size_t i = 0, n = AllocaVec.size(); i < n; i++)
>> +    AllocaVec[i]->eraseFromParent();
>> +
>>    if (ClDebugStack) {
>>      DEBUG(dbgs() << F);
>>    }
>>
>> Modified: llvm/trunk/test/Instrumentation/AddressSanitizer/basic.ll
>> URL:
>> http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Instrumentation/AddressSanitizer/basic.ll?rev=166267&r1=166266&r2=166267&view=diff
>>
>> ==============================================================================
>> --- llvm/trunk/test/Instrumentation/AddressSanitizer/basic.ll (original)
>> +++ llvm/trunk/test/Instrumentation/AddressSanitizer/basic.ll Fri Oct 19
>> 01:20:53 2012
>> @@ -69,3 +69,23 @@
>>    store i32 42, i32* %a
>>    ret void
>>  }
>> +
>> +; Check that asan leaves just one alloca.
>> +
>> +declare void @alloca_test_use([10 x i8]*)
>> +define void @alloca_test() address_safety {
>> +entry:
>> +  %x = alloca [10 x i8], align 1
>> +  %y = alloca [10 x i8], align 1
>> +  %z = alloca [10 x i8], align 1
>> +  call void @alloca_test_use([10 x i8]* %x)
>> +  call void @alloca_test_use([10 x i8]* %y)
>> +  call void @alloca_test_use([10 x i8]* %z)
>> +  ret void
>> +}
>> +
>> +; CHECK: define void @alloca_test()
>> +; CHECK: = alloca
>> +; CHECK-NOT: = alloca
>> +; CHECK: ret void
>> +
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121019/aa94a64f/attachment.html>


More information about the llvm-commits mailing list