On 11/03/2016 02:44 PM, Jakub Jelinek wrote:
> 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.
I know that it's much urgent to have it done first. I'm currently testing patch
for the switch + declaration. Hopefully I'll send it today.
>
> 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, ... ?
If there's return of *ptr, there must be a &my_char, and it looks
_4 = MEM[(char *)&my_char];
properly identifies that my_char has address taken.
M.
>
>>
>> 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
>
