On Jun 30, 2021, at 2:46 AM, Richard Biener <rguent...@suse.de<mailto:rguent...@suse.de>> wrote:
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. Yes. For cases like the following: int s2_len; s2_len = 4; i.e, the initialization is not at the declaration. We cannot avoid initialization for such cases. I'd expect to only ever see default definition SSA names as first argument to .DEFERRED_INIT. You mean something like: __s2_len_218 = .DEFERRED_INIT (__s2_len, 2); ? __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, This is unavoidable, I believe. 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. If this additional .DEFERRED_INIT will be kept till RTL expansion phase, then it will become a real initialization: i.e. s2_len = 0; //.DEFERRED_INIT expanded s2_len = 4; // the original initialization Then the first initialization will be eliminated by current RTL optimization easily, right? Qing 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 <rguent...@suse.de<mailto:rguent...@suse.de>> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
