HELP!! How to inhibit optimizations applied to .DEFERRED_INIT argument?

Richard Biener rguenther@suse.de
Wed Jun 30 07:46:19 GMT 2021


On Wed, 30 Jun 2021, Qing Zhao wrote:

> Hi, 
> 
> I am testing the 4th patch of -ftrivial-auto-var-init with CPU2017 today, and found the following issues:
> 
> ****In the dump file of “*t.i.031t.objsz1”, we have:
> 
> <bb 3> :
>   __s1_len_217 = .DEFERRED_INIT (__s1_len_176, 2);
>   __s2_len_218 = .DEFERRED_INIT (__s2_len_177, 2);

I looks like this .DEFERRED_INIT initializes an already initialized
variable.  I'd expect to only ever see default definition SSA names
as first argument to .DEFERRED_INIT.

>   __s2_len_219 = 7;
>   if (__s2_len_219 <= 3)
>     goto <bb 4>; [INV]
>   else
>     goto <bb 9>; [INV]
> 
>   <bb 4> :
>   _1 = (long unsigned int) i_175;
>  
> 
> ****However, after “ccp”, in “t.i.032t.ccp1”, we have:
> 
> <bb 3> :
>   __s1_len_217 = .DEFERRED_INIT (__s1_len_176, 2);
>   __s2_len_218 = .DEFERRED_INIT (7, 2);
>   _36 = (long unsigned int) i_175;
>   _37 = _36 * 8;
>   _38 = argv_220(D) + _37;
> 
> 
> Looks like that the optimization “ccp” replaced the first argument of the call .DEFERRED_INIT with the constant 7.
> This should be avoided. 
> 
> (NOTE, this issue existed in the previous patches, however, only exposed with this version since I added more verification
> code in tree-cfg.c to verify the call to .DEFERRED_INIT).
> 
> I am wondering what’s the best solution to this problem? 

I think you have to trace where this "bogus" .DEFERRED_INIT comes from 
originally.  Or alternatively, if this is unavoidable, add "constant 
folding" of .DEFERRED_INIT so that defered init of an initialized
object becomes the object itself, thus retain the previous - eventually
partial - initialization only.

Richard.

> Can we add any attribute to the internal function argument to prevent later optimizations that might applied on it? 
> Or just update “ccp” phase to specially handle calls to .DEFERRED_INIT? (Not sure whether there are other phases have the
> Same issue?)
> 
> Let me know if you have any suggestion.
> 
> Thanks a lot for your help.
> 
> Qing

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)


More information about the Gcc-patches mailing list