FDO usability: pid handling

[Jan Hubicka]

> 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).

If we will need density later, we can have local mapping for that.

> global func id is created based on module_id and funcdef_no.  IMO,
> using DECL_UID or cgraph_node->uid can make the implementation
> fragile.

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.

What I am shooting for is to eliminate useless data in our core datastructures
to reduce memory usage and LTO streaming.  Killing funcdef_no is obviously quite
low hanging fruit here. struct_function is quite bad in this respect as it has
been a kitchen sink for various data over a decades.

But we might pretty well use it here for time being and I will eliminate it together
with the few other uses in the compiler.

Honza
> 
> David
> 
> 
> 
> >
> > Honza
> >