On 09/13/2017 11:07 AM, Tsimbalist, Igor V wrote: >> -----Original Message----- >> From: Tsimbalist, Igor V >> Sent: Tuesday, September 12, 2017 5:59 PM >> To: 'Jeff Law' <l...@redhat.com>; 'gcc-patches@gcc.gnu.org' <gcc- >> patc...@gcc.gnu.org> >> Cc: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com> >> Subject: RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling >> >> >>> -----Original Message----- >>> From: Jeff Law [mailto:l...@redhat.com] >>> Sent: Friday, August 25, 2017 10:50 PM >>> To: Tsimbalist, Igor V <igor.v.tsimbal...@intel.com>; 'gcc- >>> patc...@gcc.gnu.org' <gcc-patches@gcc.gnu.org> >>> Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling >>> >>> On 08/01/2017 02:56 AM, Tsimbalist, Igor V wrote: >>>> Part#1. Add generic part for Intel CET enabling. >>>> >> >>> Q. Do we need to do anything with ICF (identical code folding) and CFE? >>> Given two functions which have the same implementation in gimple, >>> except that one has a notrack indirect call and the other has a >>> tracked indirect call, what is proper behavior? I think we'd keep >>> them separate which implies we need to make sure the notrack attribute >>> is part of the ICF hashing implementation. It'd probably even be >>> worth building a test for this :-) >> Are you talking about a case when such two functions are inlined? Or there is >> a possibility to merge function bodies if they are identical? >> >> I agree with you that the functions should be kept separate. I haven't looked >> into such optimization in gcc so I need to learn it. > I thought over this case and my conclusion is that nothing has to be done > regarding ICF. > > First of all let's sync on a case we are talking about. A code template could > look like > > fn1 definition > { > <some code> > } > > fn2 definition with notrack attribute > { > <the same code as in fn1> > } > > func definition > { > <calling fn1>...<calling fn2> > } > > Is it the case you are talking about? Let's consider different scenarios: > > 1) calls to fn1 and fn2 are direct calls. In that case 'notrack' has no > effect on direct calls as they are > assumed to be save (it applies to indirect calls only). ICF can be done here; > 2) one of calls is an indirect call or both calls are indirect calls. If > compiler can prove what exact functions > are called then indirect call(s) can be replaced by direct call(s) and that > gives us the case 1); > 3) if compiler cannot prove what function is called it will keep the indirect > call and so there is nothing > to do for ICF here. No, not the case I'm worried about. Instead
fn1() { indirect call where the signature is marked with notrack } fn2() { indirect call where the signature is not marked with notrack } fn1 and fn2 would be subject to ICF which I think is wrong. Essentially we're carrying semantic information in attributes that are part of the type of the function pointer. I think we need to include those attributes when we hash and compare two objects for equality within ICF. Jeff