Re: [RFC][PATCH] Speed-up use-after-scope (re-writing to SSA)

[Martin Liška <mliska at suse dot cz>]

On 12/02/2016 01:29 PM, Richard Biener wrote:
> On Thu, Dec 1, 2016 at 5:30 PM, Martin Liška <mliska@suse.cz> wrote:
>> On 11/23/2016 03:13 PM, Jakub Jelinek wrote:
>>> On Wed, Nov 23, 2016 at 02:57:07PM +0100, Martin Liška wrote:
>>>> I started review process in libsanitizer: https://reviews.llvm.org/D26965
>>>> And I have a question that was asked in the review: can we distinguish between load and store
>>>> in case of having usage of ASAN_POISON?
>>>
>>> I think with ASAN_POISON it is indeed just loads from after scope that can
>>> be caught, a store overwrites the variable with a new value and when turning
>>> the store after we make the var no longer addressable into SSA form, we
>>> loose information about the out of scope store.  Furthermore, if there is
>>> first a store and then a read, like:
>>>   if (argc != 12312)
>>>     {
>>>       char my_char;
>>>       ptr = &my_char;
>>>     }
>>>   *ptr = i + 26;
>>>   return *ptr;
>>> we don't notice even the read.  Not sure what could be done against that
>>> though.  I think we'd need to hook into the into-ssa framework, there it
>>> should know the current value of the variable at the point of the store is
>>> result of ASAN_POISON and be able to instead of turning that
>>>   my_char = _23;
>>> into
>>>   my_char_35 = _23;
>>> turn it into:
>>>   my_char_35 = ASAN_POISON (_23);
>>> which would represent after scope store into my_char.
>>>
>>> Not really familiar with into-ssa though to know where to do it.
>>>
>>>       Jakub
>>>
>>
>> Richi, may I ask you for help with this question?
> 
> Probably where we handle the CLOBBER case (rewrite_stmt, maybe_register_def),
> we do this for -Wuninitialized.
> 
> Richard.

Thanks for the tip, however as the optimization of memory address store + load happens
before we rewrite my_char into SSA, it would be probably hard to guess which memory
stores and loads should be preserved:

use-after-scope-20.c.032t.ccp1:
main (int argc, char * * argv)
{
  int my_char;
  int * ptr;
  int _1;
  int _11;

  <bb 2> [0.0%]:
  if (argc_4(D) != 12312)
    goto <bb 3>; [0.0%]
  else
    goto <bb 4>; [0.0%]

  <bb 3> [0.0%]:
  ASAN_MARK (2, &my_char, 4);
  ptr_8 = &my_char;
  ASAN_MARK (1, &my_char, 4);

  <bb 4> [0.0%]:
  # ptr_2 = PHI <ptr_5(D)(2), ptr_8(3)>
  _1 = argc_4(D) + 26;
  *ptr_2 = _1;
  _11 = *ptr_2;
  return _11;

}

I sent updated version of patch to LLVM phabricator:
https://reviews.llvm.org/D26965

Hopefully we can cherry pick the patch very soon to our trunk.

M.

> 
>> Thanks,
>> Martin
>>