This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 12/22/2016 06:21 PM, Jakub Jelinek wrote:
> On Thu, Dec 22, 2016 at 06:03:50PM +0100, Martin Liška wrote:
>> Done by hash_map.
> 
> Ok.
> 
>>> 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 ;)
> 
> Ok.
> 
>>> 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;
>>
>> }
> 
> But we do not want to rewrite into SSA that way, but instead as
> 
> main (int argc, char * * argv)
> {
>   int a;
>   int * ptr;
>   int _8;
> 
>   <bb 2> [0.00%]:
>   a_9 = 12345;
>   a_10 = ASAN_POISON ();
>   ASAN_POISON (a_10);
>   a_11 = 12345;
>   _8 = a_11;
>   return _8;
> 
> }

I'm still not sure how to do that. Problem is that transformation from:

  ASAN_MARK (UNPOISON, &a, 4);
  a = 5;
  ASAN_MARK (POISON, &a, 4);

to 

  a_8 = 5;
  a_9 = ASAN_POISON ();

happens in tree-ssa.c, after SSA is created, in situation where we prove the 'a'
does not need to live in memory. Thus said, question is how to identify that we
need to transform into SSA in a different way:

   a_10 = ASAN_POISON ();
   ASAN_POISON (a_10);

Thanks for help,
Martin

> 
> or something similar, so that you can 1) emit a diagnostics at the spot
> where the out of scope store happens 2) differentiate between reads from
> out of scope var and stores to out of scope var
> 
> What we need is to hook into tree-into-ssa.c for this, where a_11 is
> created, find out that there is a store to a var that has ASAN_POISON result
> as currently active definition.  Something like if we emit ASAN_POISON
> for some var, during tree-into-ssa.c if we see a store to that var that we
> need to rewrite into SSA pretend there is a read from that var first at
> that location and if it is result of ASAN_POISON, emit the additional
> stmt.
> 
> 	Jakub
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]