Discard this version of the patch. I have not updated source properly and the build/test was invalid.
David On Wed, Apr 20, 2011 at 11:22 AM, Xinliang David Li <davi...@google.com> wrote: > Here is the revised patch. Basic FDO testing went fine. I still saw > the ipa-inline assertion in SPEC FDO. Will run it when the regression > is fixed. > > Thanks, > > David > > On Tue, Apr 19, 2011 at 5:33 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >>> On Tue, Apr 19, 2011 at 4:49 PM, Jan Hubicka <hubi...@ucw.cz> wrote: >>> >> Actually, among all the choices, funcdef_no is probably the most dense >>> >> one -- it is for function decl with definition only. In LIPO, the >>> > >>> > Yes, funddef_no is densiest, but we don't really need great density here >>> > (in many other places we index arrays by cgraph_uid - it is intended for >>> > that purpose and we pay some attention to recycle unused nodes). >>> > >>> >>> That does not mean it is right to use sparse ids:) DECL_UID will be >>> the worst amongst them. >> >> Sure, that is why I suggested cgraph->uid. That one is kept dense and it >> also >> tracks cgraph node creation order. Unlike pid it counts also functions w/o >> bodies. >>> > We only care to avoid divergence in the indexes in between instrumentation >>> > and feedback compilation. With the IPA pass organizatoin the compiler >>> > doesn't >>> > really diverge until the profile pass, so it seems to me that all should >>> > be safe. >>> >>> When I said 'fragile' -- I meant it depends on the optimization pass >>> phase ordering which can change in the future. >> >> Well, that is the case of all of them (passes can create function bodies that >> can make funcdef_no also diverge). This is the case of couple passes >> already, >> especially OMP lowering and friends. >> >>> Ok, I will throw away pid and use funcdef_no for now. For future >>> replacement for the function ids, please consider the following >>> desired properties: >>> >>> 1) The id sequence does not depend on optimization passes -- only >>> depend on source/parsing order; >> >> It depends on optimization, too. This is why we actually have cgraph->order >> that is used for -fno-toplevel-reorder and is similar to funcdef_no, but >> assigned at finalization time. >> >>> 2) It is dense and sequential for defined functions >>> a) it has proven to be very useful to use nice looking, sequential >>> ids in triaging coverage mismatch related problems (the tree dump >>> should also show the function id); >> >> You get the cgraph uids in the dumps already. >>> b) it can be very useful in bug triaging via binary search by >>> specifying ranges of function ids (to enable optimizations etc). >> >> But as you wish, we can process with fundef_no first and then discuss >> removal of that field later. >> >> Honza >>> >>> Thanks, >>> >>> David >>> >>> >>> > >>> > Honza >>> >> >>> >> David >>> >> >>> >> >>> >> >>> >> > >>> >> > Honza >>> >> > >>> > >> >
