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
