Re: 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  > 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
> 

Re: Creating a wrapper around a function at compile time

[Erick Ochoa via Gcc]

Awesome! Thanks!

Let's go a little bit into the transformation mechanics itself. I am
somewhat familiar with LTO but I am always confused about the
transformations scheduled during WPA.

Let's assume that:

1. we have the profiling pass, which profiles each argument in each
callsite.
2. we are now running in the -fprofile-use so that means that we have
access to the value profiles for each of the arguments
3. there's an IPA/LTO pass which creates edge summaries storing "likely"
values for each of callsite/argument
4. we have a heuristic that let's us decide to some extent which subset of
likely values will yield good results (heavily used and specialization is
greatly beneficial if found) and run it during WPA.

Then, what happens next? I know that the idea is to create some parameter
tests at the callsite and call the respective parameter. The gap in my
understanding is that at this point I am assuming we are in WPA and
therefore have no function bodies to add these parameter tests. Would it be
sufficient to do the following:

1. Store in optimization (edge) summaries the (argument position x value x
specialized function version)
2. During LTRANS actually perform the transformation for the parameter test

Or is there some other way? I am still working on understanding how
ipa_make_edge_direct_to_target with speculative = true adds the edge and
function test during WPA. Otherwise, if we go with the two steps above, the
edges won't be visible to the rest of the IPA optimizations.

I'll be reading the cgraph_edge::make_speculative and the rest of the
infrastructure a bit more closely...

Any help or direction is greatly appreciated. Thanks!

-Erick

Re: Proposal: allow to extend C++ template argument deduction via plugins

[Ben Boeckel via Gcc]

On Thu, Jul 14, 2022 at 18:46:47 +0200, Dan Klishch via Gcc wrote:
> As far as I understand the currently available plugin extension points, it is
> not possible to modify template argument deduction algorithm (except the
> theoretical possibility to completely override parsing step). However, such
> opportunity might be beneficial for projects like libpqxx, for example, when
> database schema and query text are available at compile-time, return types of
> the query might be inferred by the plugin.
> 
> I propose to add something like PLUGIN_FUNCTION_CALL plugin_event which will
> allow to modify function calls conditionally. Will a patch adding such
> functionality be welcomed?

Note that I'm not a GCC developer, so my opinion isn't worth much on the
acceptability-to-GCC front.

Wouldn't this make it a C++ dialect? How would non-GCC compilers be able
to be compatible with such an API? That is, if the schema and query
being available changes the API (nevermind the schema itself changing),
I don't see how this works in general.

--Ben

Re: [PATCH Linux] powerpc: add documentation for HWCAPs

[Segher Boessenkool]

On Fri, Jul 15, 2022 at 11:17:24AM +1000, Nicholas Piggin wrote:
> Excerpts from Segher Boessenkool's message of May 25, 2022 4:32 am:
> > Linux runs on ISA 1.xx and ISA 2.01 machines still.  "Category" wasn't
> > invented for either yet either, but similar concepts did exist of
> > course.
> 
> Not sure what to say about this. It now also has "Compliancy Subset"
> although maybe that's more like a set of features rather than
> incompatible features or modes such as some of the category stuff
> seems to be. I'll try add something.

The compliancy subset stuff is an attempt to simplify things again.
In most cases you want to require a whole swath of feature at once,
if you really try to support fine-grained optional features you need to
test thousands of configurations, while you really can test only ten
(if you are lucky!)

Maybe it is best to just be a bit vague here?


Segher

Re: [PATCH v2] powerpc: add documentation for HWCAPs

[Segher Boessenkool]

On Fri, Jul 15, 2022 at 11:26:36AM +1000, Nicholas Piggin wrote:
> Take the arm64 HWCAP documentation file and adjust it for powerpc.
> 
> Signed-off-by: Nicholas Piggin 

Reviewed-by: Segher Boessenkool 

> +2. Facilities
> +-
> +
> +The Power ISA uses the term "facility" to describe a class of instructions,
> +registers, interrupts, etc. The presence or absence of a facility indicates
> +whether this class is available to be used, but the specifics depend on the
> +ISA version. For example, if the VSX facility is available, the VSX
> +instructions that can be used differ between the v3.0B and v3.1B ISA
> +versions.

The term "facility" is never defined in the architecture documents, so
the common language meaning applies, which google says is "a place,
amenity, or piece of equipment provided for a particular purpose", which
fits your explanation well.

> +3. Categories
> +-
> +
> +The Power ISA before v3.0 uses the term "category" to describe certain
> +classes of instructions and operating modes which may be optional or
> +mutually exclusive, the exact meaning of the HWCAP flag may depend on
> +context, e.g., the presence of the BOOKE feature implies that the server
> +category is not implemented.

Since ISA 3.0 the preface says
  The resulting architecture included [...] and optional application-
  specific facilities (categories) as extensions to a pervasive base
  architecture.
which fits your explanation.

Thanks for improving the documentation!


Segher

Re: Proposal: allow to extend C++ template argument deduction via plugins

[Dan Klishch via Gcc]

Hi Ben,

Thanks for your feedback. The original problem I was trying to solve is to do
such deduction in my own project where I use self-written wrapper around libpq,
so naturally I'm not concerned if I'll be writing in pure C++ or C++ dialect.

Actually, I tried to come up with a solution which makes as many opportunities
open as possible, so it also allows to create almost any kind of decorators or
magic functions, for instance, __builtin_format from here
.

Using plugins means that we are doing something incompatible somewhere and are
fully aware of that. Furthermore, one already has a restricted ability to make
arbitrary modifications to AST with the help of plugins via registering new
pragmas and attributes, so I just only want to loosen restrictions.

Returning to the use case regarding libpqxx, one can make specifying return
types optional when compiling with a plugin and mandatory otherwise. So then if
the code is compiled with the plugin, schema and query available and types are
not omitted, the plugin can check the types instead of inferring. Also, I
believe the aforementioned is possible in Haskell (I only briefly read project
description) .

Thanks,
Dan Klishch

On 7/15/2022 4:18 PM, Ben Boeckel wrote:


On Thu, Jul 14, 2022 at 18:46:47 +0200, Dan Klishch via Gcc wrote:

As far as I understand the currently available plugin extension points, it is
not possible to modify template argument deduction algorithm (except the
theoretical possibility to completely override parsing step). However, such
opportunity might be beneficial for projects like libpqxx, for example, when
database schema and query text are available at compile-time, return types of
the query might be inferred by the plugin.

I propose to add something like PLUGIN_FUNCTION_CALL plugin_event which will
allow to modify function calls conditionally. Will a patch adding such
functionality be welcomed?

Note that I'm not a GCC developer, so my opinion isn't worth much on the
acceptability-to-GCC front.

Wouldn't this make it a C++ dialect? How would non-GCC compilers be able
to be compatible with such an API? That is, if the schema and query
being available changes the API (nevermind the schema itself changing),
I don't see how this works in general.

--Ben

Re: [PATCH v2] powerpc: add documentation for HWCAPs

[Tulio Magno Quites Machado Filho via Gcc]

Nicholas Piggin  writes:

> +PPC_FEATURE_ARCH_2_05
> +The processor supports the v2.05 userlevel architecture. Processors
> +supporting later architectures also set this feature.

I don't think this bit is enabled when processors support later architectures.
In my tests, this behavior started only with v2.06, i.e. processors that
support v2.07 enable bit v2.06, but do not enable bit v2.05.

Otherwise, looks good to me.

-- 
Tulio Magno

Re: [PATCH v2] powerpc: add documentation for HWCAPs

[Segher Boessenkool]

On Fri, Jul 15, 2022 at 03:41:20PM -0300, Tulio Magno Quites Machado Filho 
wrote:
> Nicholas Piggin  writes:
> 
> > +PPC_FEATURE_ARCH_2_05
> > +The processor supports the v2.05 userlevel architecture. Processors
> > +supporting later architectures also set this feature.
> 
> I don't think this bit is enabled when processors support later architectures.
> In my tests, this behavior started only with v2.06, i.e. processors that
> support v2.07 enable bit v2.06, but do not enable bit v2.05.

That is a usability problem.  Can it be fixed, or will that create its
own compatibility problems?  In practice I mean.  If it is, the C
libraries could fix it up, for new programs, and then after a while the
kernel can do the sane thing?

How big is the problem, anyway?  Is it only 2.05, or also 2.04, 2.03?


Segher

Re: [PATCH v2] powerpc: add documentation for HWCAPs

[Tulio Magno Quites Machado Filho via Gcc]

Segher Boessenkool  writes:

> That is a usability problem.  Can it be fixed, or will that create its
> own compatibility problems?  In practice I mean.  If it is, the C
> libraries could fix it up, for new programs, and then after a while the
> kernel can do the sane thing?
>
> How big is the problem, anyway?  Is it only 2.05, or also 2.04, 2.03?

PPC_FEATURE_ARCH_2_05 is the first bit referring to an ISA level.
Before that, AT_HWCAP used to have bits for specific processors, e.g.
PPC_FEATURE_CELL and PPC_FEATURE_POWER4.

Notice that glibc creates its own hwcap-based information that is used by
__builtin_cpu_supports().  In this case bits PPC_FEATURE_ARCH_2_05,
PPC_FEATURE_POWER5_PLUS, PPC_FEATURE_POWER5 and PPC_FEATURE_POWER4 are enabled
whenever if the processor is compatible with the features provided by any of
the previous processors [1].
AT_HWCAP and AT_HWCAP2 are kept intact, though.

[1] 
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/powerpc/hwcapinfo.c;h=afde05f86382413ce1f0c38e33c9bdd38d6b7e9d;hb=HEAD#l45

-- 
Tulio Magno

gcc-11-20220715 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20220715 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20220715/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision 0db2a65ffddc1f47209f031add9e9306a664588a

You'll find:

 gcc-11-20220715.tar.xz   Complete GCC

  SHA256=cdd08b6c3179ef27adef735a1125483d81de1f305282017c9f2b259458459581
  SHA1=4a1ad20479d0b33c7190d321e69076417402a655

Diffs from 11-20220708 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.