Hi! FYI, I think it is much more important to get the initial patch in, so resolve the switch + declarations inside of its body stuff, add testcases for that and post for re-review and check in. These optimizations can be done even in stage3.
On Thu, Nov 03, 2016 at 02:34:47PM +0100, Martin Liška wrote: > I'm having a semi-working patch that comes up with the ASAN_POISON built-in. > Well, to be honest, > I still have a feeling that doing the magic with the parallel variable is bit > overkill. Maybe > a new runtime call would make it easier for us. > > However, I still don't fully understand why we want to support just > is_gimple_reg variables. > Let's consider following test-case: > > void foo() > { > char *ptr; > { > char my_char[9]; > ptr = &my_char[0]; > } > } > > Where I would expect to optimize out: > <bb 2>: > _5 = (unsigned long) 9; > _4 = (unsigned long) &my_char; > __builtin___asan_unpoison_stack_memory (_4, _5); > _7 = (unsigned long) 9; > _6 = (unsigned long) &my_char; > __builtin___asan_poison_stack_memory (_6, _7); > return; > > where address of my_char is taken in the original source code, while not > during tree-ssa > optimization, where the address is used only by ASAN_MARK calls. But how would you be able to find out if there isn't any return *ptr; after the scope or similar (as MEM_REF)? With is_gimple_reg, they will be turned into SSA form and you can easily verify (uses of ASAN_POISON are a problem if they are encountered at runtime). What would you do for the must_live_in_memory vars? Add some pass that detects it, handle it somehow in addressable pass, handle it in SRA, ... ? > > Doing such transformation can rapidly decrease number of > __builtin___asan_{un}poison_stack_memory > in tramp3d: from ~36K to ~22K. > > Thanks for clarification. > Martin Jakub