[PATCH] Speed-up use-after-scope (re-writing to SSA) (version 2)

[Martin Liška]

On 12/21/2016 09:52 AM, Jakub Jelinek wrote:
> On Tue, Dec 20, 2016 at 12:26:41PM +0100, Martin Liška wrote:
>> Ok, llvm folks are unwilling to accept the new API function, thus I've decided to come up
>> with approach suggested by Jakub. Briefly, when expanding ASAN_POISON internal function,
>> we create a new variable (with the same name as the original one). The variable is poisoned
>> at the location of the ASAN_POISON and all usages just call ASAN_CHECK that would trigger
>> use-after-scope run-time error. Situation where ASAN_POISON has a LHS is very rare and
>> is very likely to be a bug. Thus suggested not super-optimized approach should not be
>> problematic.
> 
> Do you have a testcase for the case where there is a write to the var after
> poison that is then made non-addressable?  use-after-scope-9.c only covers
> the read.
> 
>> I'm not sure about the introduction of 'create_var' function, maybe we would need some
>> refactoring. Thoughts?
> 
> It doesn't belong to gimple-expr.c and the name is way too generic, we have
> many create var functions already.  And this one is very specialized.
> 
>> 2016-12-19  Martin Liska  <mliska@suse.cz>
>>
>> 	* asan.c (asan_expand_poison_ifn): New function.
>> 	* asan.h (asan_expand_poison_ifn):  Likewise.
> 
> Too many spaces.
> 
>> +  tree shadow_var = create_var (TREE_TYPE (poisoned_var),
>> +				IDENTIFIER_POINTER (DECL_NAME (var_decl)));
> 
> For the shadow var creation, IMHO you should
> 1) use a hash table, once you add a shadow variable for a certain variable
>    for the first time, reuse it for all the other cases; you can have many
>    ASAN_POISON () calls for the same underlying variable

Thanks for review.

Done by hash_map.

> 2) as I said, use just a function in sanopt.c for this,
>    create_asan_shadow_var or whatever

Also done.

> 3) I think you just want to do copy_node, plus roughly what
>    copy_decl_for_dup_finish does (and set DECL_ARTIFICIAL and
>    DECL_IGNORED_P) - except that you don't have copy_body_data
>    so you can't use it directly (well, you could create copy_body_data
>    just for that purpose and set src_fn and dst_fn to current_function_decl
>    and the rest to NULL)

I decided to use the function with prepared copy_body_data ;)

> 
> I'd really like to see the storing to poisoned var becoming non-addressable
> in action (if it can ever happen, so it isn't just theoretical) to look at
> what it does.

Well, having following sample:

int
main (int argc, char **argv)
{
  int *ptr = 0;

  {
    int a;
    ptr = &a;
    *ptr = 12345;
  }

  *ptr = 12345;
  return *ptr;
}

Right after rewriting into SSA it looks as follows:

main (int argc, char * * argv)
{
  int a;
  int * ptr;
  int _8;

  <bb 2> [0.00%]:
  a_9 = 12345;
  a_10 = ASAN_POISON ();
  a_11 = 12345;
  _8 = a_11;
  return _8;

}

Thus, I guess it not possible to do a write.

Following v2 can bootstrap on ppc64le-redhat-linux and survives regression tests.

Martin

> 
> 	Jakub
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Speed-up-use-after-scope-v2-rewrite-into-SSA-v2.patch
Type: text/x-patch
Size: 13824 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20161222/27f0b09c/attachment.bin>