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

Qing Zhao qing.zhao@oracle.com
Wed Jun 30 00:14:02 GMT 2021


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);
  __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? 

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


More information about the Gcc-patches mailing list