Creating a wrapper around a function at compile time

[Martin Liška]

On 7/14/22 16:25, Erick Ochoa wrote:
> 
> 
> On Thu, 14 Jul 2022 at 16:10, Martin Liška <mliska@suse.cz <mailto:mliska@suse.cz>> wrote:
> 
>     On 7/14/22 16:08, Erick Ochoa via Gcc wrote:
>     > Last time I checked, value profiling can only track a single value per
>     > statement.
> 
>     Hi.
> 
>     Take a look at HIST_TYPE_INDIR_CALL which we use for tracking at maximum 32
>     (#define GCOV_TOPN_MAXIMUM_TRACKED_VALUES 32) and we use for indirect call
>     speculative calls which you can see for instance here:
> 
>     ./gcc/testsuite/g++.dg/tree-prof/indir-call-prof.C
> 
> 
> Thanks Martin,
> 
> I'll give it a read. However, I have mis-spoken. If my understanding is correct: multiple values are tracked, but only the values of a single variable/expression per statement are tracked. That means that for a gcall (which is a single statement and) which has n argument expressions, I believe that the naive way to track all argument expressions is not possible without extending how histograms are associated to statements. Perhaps canonicalizing how callsites work (i.e., only variables are allowed as arguments in call sites and then associating a histogram to the definition of the variables being used in call sites) would be enough, but I haven't given it much thought for the consequences that might follow from this.

Yes, you are correct that we track only one type of histogram per each gimple statement:

histogram_value
gimple_histogram_value_of_type (struct function *fun, gimple *stmt,
				enum hist_type type)
{
  histogram_value hist;
  for (hist = gimple_histogram_value (fun, stmt); hist;
       hist = hist->hvalue.next)
    if (hist->type == type)
      return hist;
  return NULL;
}

but that could be theoretically relaxed for your use-case.

Cheers,
Martin

>  
> 
> 
>     Cheers,
>     Martin
>