Re: Push to my private branches is disallowed

[Martin Jambor]

Hi,

On Mon, Jun 15 2020, Segher Boessenkool wrote:
> Hi!
>
[...]
> What.
>
> Of course it is not a fast-forward.  I rebase the branches I publish,
> what is the point of publishing them otherwise?  This is so that people
> can see the stuff that will make its way into master *later*.
>
> The number of new commits is nonsense (it is just 13), and the number of
> emails that triggers should be 0.
>
> Please fix?  Or, what else is wrong?

while I tend to agree that sending emails about commits to user branches
is not a good idea, I also believe that you should (almost?) never
rebase a public branch.  Certainly not if you expect anyone else to
fetch it or - god forbid - base some of their commits on it, as opposed
to just reading it through the web interface.  I'd suggest appending a
date to the namer of the branch and thus always publish a new branch,
making it clear that its history is different.

Martin

Re: SSA_NAME_DEF_STMT or print_gimple_stmt for MEM_REF seems mal-functional

[Richard Biener via Gcc]

On Tue, Jun 16, 2020 at 5:00 AM Shuai Wang  wrote:
>
> Yes,  TREE_CODE (op1) != SSA_NAME shows that op1 is by no means SSA names 
> (although I don't know why). But how can I backwardly identify its 
> initialization statement _17 = (signed char *) _16? Thanks!

You want to walk over SSA operands of the stmt, not over operands
using for example FOR_EACH_SSA_USE_OPERAND.

> Shuai
>
> On Tue, Jun 16, 2020 at 10:32 AM Shuai Wang  wrote:
>>
>> Got it. But in that sense, given a `op1` satisfies the 
>> "is_gimple_addressable" predicate (e.g., the _17 in my sample code), how can 
>> I find its def statement? Thank you very much.
>>
>> Shuai
>>
>> On Tue, Jun 16, 2020 at 3:19 AM Richard Biener  
>> wrote:
>>>
>>> On June 15, 2020 6:58:27 PM GMT+02:00, Shuai Wang  
>>> wrote:
>>> >Thank you very much for your prompt response, Rchard. Sorry I was kinda
>>> >"learning by doing". I am familiar with LLVM stuff but newbie to GCC
>>> >specifications.
>>> >
>>> >Just want to make sure I got it right; _17 and _16 in the IR code are
>>> >SSA
>>> >variables. They are initialized for once and used once. Could you
>>> >please
>>> >shed some light on where "non-ssa name" comes in this scenario, and how
>>> >exactly can I get  _17 = (signed char *) _16 printed out? Thank you
>>> >very
>>> >much.
>>> >
>>> >Best,
>>> >Shuai
>>> >
>>> >On Tue, Jun 16, 2020 at 12:52 AM Richard Biener
>>> >
>>> >wrote:
>>> >
>>> >> On June 15, 2020 6:31:38 PM GMT+02:00, Shuai Wang via Gcc
>>> >
>>> >> wrote:
>>> >> >Hello,
>>> >> >
>>> >> >Suppose given the following SSA statement generated by the `sanopt`
>>> >> >pass:
>>> >> >
>>> >> >   _17 = (signed char *) _16;
>>> >> >   _18 = *_17;
>>> >> >
>>> >> >I am using the following code to identify that _17 depends on _16:
>>> >> >
>>> >> >// def_stmt refers to _18 = &_17;
>>> >> >for (unsigned i = 1; i < gimple_num_ops(def_stmt); i++) {
>>> >> > op1 = gimple_assign_rhs1(def_stmt);
>>>
>>> op1 is not an SSA name here.
>>>
>>> >> > if (is_gimple_addressable(op1))
>>>
>>> That predicate does not make sense on SSA names
>>>
>>>  {
>>> >> >  gimple* def_stmt = SSA_NAME_DEF_STMT(op1);
>>> >> >  print_gimple_stmt(stderr, def_stmt, 0, TDF_SLIM); // crash
>>> >at
>>> >> >this point
>>> >> > }
>>> >> >
>>> >> >It crashes with the following call stack:
>>> >> >
>>> >> >0xb5cd5f crash_signal
>>> >> >../../gcc-10.1.0/gcc/toplev.c:328
>>> >> >0x1452134 pp_format(pretty_printer*, text_info*)
>>> >> >../../gcc-10.1.0/gcc/pretty-print.c:1828
>>> >> >0x14533e4 pp_printf(pretty_printer*, char const*, ...)
>>> >> >../../gcc-10.1.0/gcc/pretty-print.c:1773
>>> >> >0x8dcc81 print_gimple_stmt(_IO_FILE*, gimple*, int, dump_flag)
>>> >> >../../gcc-10.1.0/gcc/gimple-pretty-print.c:157
>>> >> >
>>> >> >I tried hard but just cannot understand why this would crash.
>>> >Indeed,
>>> >> >this
>>> >> >code works pretty well when printing out other dependency
>>> >statements,
>>> >> >but
>>> >> >just gets stuck in front of pointer dereference like _18 = *_17.
>>> >> >
>>> >> >Any suggestion would be appreciated. Thank you!
>>> >>
>>> >> Build your compiler with - - enable-checking and you'll figure you
>>> >> reference SSA_NAME_DEF_STMT of a NON-SSA_NAME. I suggest you learn to
>>> >use a
>>> >> debugger.
>>> >>
>>> >> Richard.
>>> >>
>>> >> >Best,
>>> >> >Shuai
>>> >>
>>> >>
>>>

Re: SLP and dr_vec_info

[Richard Sandiford]

Richard Biener  writes:
> I'm facing the issue that we have vector type dependent information
> stored in dr_vec_info (the misalignment at least) and that with
> BB vectorization (at least) we want to be able to access a DR group with
> two different vector types.
>
> I've run into this with 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547981.html and
> created the testcase 
> https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547987.html
> in response to the fallout.
>
> I'm thinking of ways to circumvent this issue.  In the end when
> we're SLP only my idea was that the stmt_vec_info (and thus the
> embedded dr_vec_info) only contain data that is valid in all
> possible SLP contexts.  While we still have both SLP and non-SLP
> paths the approach of duplicating things on the SLP node becomes
> too complicated in most cases.  So one possible "fix" is to put
> conservative values in dr_vec_info - for the misalignment this
> means consider the values of the vector type with the largest
> target alignment.  Another possible fix is to not store anything
> vector type dependent there but compute such info in the places
> where we need it which then need to pass the actual vector type
> used.

It looks like all the information except for:

  /* The data reference itself.  */
  data_reference *dr;
  /* The statement that contains the data reference.  */
  stmt_vec_info stmt;

is really per-vector-stmt(-group) rather than per-scalar-stmt.
And “stmt” is really just there to provide a cheaper alternative
to a lookup_stmt on the DR_STMT.

So in an all-SLP world, it looks like the whole of dr_vec_info should
be per SLP node rather than per stmt_vec_info (possibly without the
“stmt” field if it isn't useful then).

During the transition period, could we store the dr_vec_infos
separately from the stmt_vec_infos, and just have pointers to
them in the stmt_vec_info instead?  Then we could do the usual
“if slp_node is nonnull, get the information from there, otherwise
get it from stmt_info“ routine.

Maybe it would be worth having an SLP node pointer in the dr_vec_info
for reverse lookups?

Probably none of that was helpful, sorry…

Richard

Re: Push to my private branches is disallowed

[Jonathan Wakely via Gcc]

On Tue, 16 Jun 2020 at 10:11, Martin Jambor  wrote:
>
> Hi,
>
> On Mon, Jun 15 2020, Segher Boessenkool wrote:
> > Hi!
> >
> [...]
> > What.
> >
> > Of course it is not a fast-forward.  I rebase the branches I publish,
> > what is the point of publishing them otherwise?  This is so that people
> > can see the stuff that will make its way into master *later*.
> >
> > The number of new commits is nonsense (it is just 13), and the number of
> > emails that triggers should be 0.
> >
> > Please fix?  Or, what else is wrong?
>
> while I tend to agree that sending emails about commits to user branches
> is not a good idea, I also believe that you should (almost?) never
> rebase a public branch.  Certainly not if you expect anyone else to
> fetch it or - god forbid - base some of their commits on it, as opposed
> to just reading it through the web interface.  I'd suggest appending a
> date to the namer of the branch and thus always publish a new branch,
> making it clear that its history is different.

I see no harm in rebasing public branches as long as nobody expects
otherwise. A public branch on gcc.gnu.org under refs/heads that is
being pulled by unknown persons and used in unknown forks for unknown
purposes shouldn't be rebased, because you don't know who you're
causing problems for by doing so. But a personal branch like Segher's
could disappear at any time. If we're going to discourage rebasing, we
should also discourage deleting personal branches. But I don't see any
benefit to that.

If I create a branch refs/users/redi/work-in-progress for somebody
else to look at and then delete it, do I have to remember never to
create another branch using that name in future, in case somebody
pulled the old branch before I deleted it?

Randos on the internet aren't going to be basing work on those
branches accidentally, they're not fetched by default so you have to
make some non-trivial effort to even fetch them. If you do that, you
should know you're not using an official GCC branch, but one that
Segher can rebase or completely delete at any time.

I think only the owner of a personal branch should decide what
workflow and rebasing policies apply to that branch.

Re: Push to my private branches is disallowed

[Segher Boessenkool]

Hi!

On Tue, Jun 16, 2020 at 11:11:01AM +0200, Martin Jambor wrote:
> On Mon, Jun 15 2020, Segher Boessenkool wrote:
> > What.
> >
> > Of course it is not a fast-forward.  I rebase the branches I publish,
> > what is the point of publishing them otherwise?  This is so that people
> > can see the stuff that will make its way into master *later*.
> >
> > The number of new commits is nonsense (it is just 13), and the number of
> > emails that triggers should be 0.
> >
> > Please fix?  Or, what else is wrong?
> 
> while I tend to agree that sending emails about commits to user branches
> is not a good idea, I also believe that you should (almost?) never
> rebase a public branch.

It is *my* branch.  Containing *my* work.  So I rebase it whenever I need
to refactor it, or simply when the base changed (there *are* commits to
trunk after all ;-) ).

The reason to make this work "public" is so that other people can follow
it.  It *has to* rebase in any case, if you want it to converge on what
will eventually be submitted, instead of diverging wildly from that.

Since merges aren't allowed at all on trunk (and that is a very good
thing), all work destined for trunk *has to* rebase.

So, the *common* case for user branches is that they rebase (and some
others will just not change at all ever, until they are deleted).

> Certainly not if you expect anyone else to
> fetch it or - god forbid - base some of their commits on it, as opposed
> to just reading it through the web interface.  I'd suggest appending a
> date to the namer of the branch and thus always publish a new branch,
> making it clear that its history is different.

This is easy to deal with for those users, too.  They just have to know
the branch rebases.


Segher

Re: Push to my private branches is disallowed

[Joseph Myers]

On Tue, 16 Jun 2020, Jonathan Wakely via Gcc wrote:

> I see no harm in rebasing public branches as long as nobody expects
> otherwise.

And by design you *can* rebase user and vendor branches (but not those in 
other namespaces).  The message about not being a fast-forward is just a 
warning, not an error.

-- 
Joseph S. Myers
jos...@codesourcery.com

RFC/RFH - proof of concept for GCC OpenMP 5.0 non-rectangular worksharing-loop implementation

[Jakub Jelinek via Gcc]

Hi!

Before OpenMP 5.0, all OpenMP loop nests had to be rectangular (and OpenMP
has various other restrictions that make implementation easier), so that it
was very easy to compute the number of iterations of the collapsed loop
by computing number of iterations of each of the loops in the loop nest
and multiplying them; then either inline code or runtime library from that
total number of iterations, the thread number, number of threads in the team
and scheduling policies can determine an interval of logical iterations
which the thread will handle and then it was fairly cheap to compute from
that single 0 .. num_iterations-1 iterator what iterator values it starts
with.

For non-rectangular loops, this is getting harder, both how to compute
the number of iterations and how to cheaply if possible from the single
logical number iteration start compute the different iterator values.

Below is a proof of concept of what I came up so far.  I have tried
to list the relevant restrictions in OpenMP in the first big comment in bar
function, foo function has #if 0 what I'm trying to implement and #else
a version that does it serially in a single thread only, and then bar
is an attempt to write in C what GCC could roughly emit for it.
Note, the test uses (mostly) int types, but in reality it can be other
integral types, signed or unsigned, and OpenMP just adds assurances that
the loops will not wrap around and otherwise behave well.

For both number of iterations computation and the logical iteration to
actual iterator values computations I have two versions, one lame fallback
which worst case let's each thread basically run the whole loop as is except
for the body.  This one is because I don't want to spend months on it and
deal with Bernoulli constants for 120 nested loops etc., so something that
will be standard compliant and for loops that have costly body will be
beneficial too.  And then an optimized version, for now limited to
triangular loops (can be used also if there are rectangular loops around
those), where the first part tries to compute total number of iterations
using Faulhaber's formula and the second part attempts to compute quadratic
equation root using integer square root.

The proof of concept right now uses the fallback even if it sees that the
inner loop will not have at least a single iteration for all values of the
outer loop iterator, will try to change that to just artificially change
the a and b values (bounds of the outer iterator) for the purposes of total
number of iterations computation and for the purpose of transforming the
quadratic equation root into the actual iterator values (and keep the
original ones for the purpose of computing lastprivate iterator values).

Any thoughts on how to simplify this, what to do differently, whether e.g.
using floating point math instead would be beneficial etc.?
Any input appreciated.

/* Proof of concept for OpenMP non-rectangular worksharing-loop
   implementation.
   Copyright (C) 2020 Free Software Foundation, Inc.

   GCC is free software; you can redistribute it and/or modify it under
   the terms of the GNU General Public License as published by the Free
   Software Foundation; either version 3, or (at your option) any later
   version.

   GCC is distributed in the hope that it will be useful, but WITHOUT ANY
   WARRANTY; without even the implied warranty of MERCHANTABILITY or
   FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
   for more details.

   You should have received a copy of the GNU General Public License
   along with GCC; see the file COPYING3.  If not see
   .  */

#include 
#include 
#ifdef _OPENMP
#include 
#endif

int x, i, j, nitersv, niterscnt;

#ifdef DEBUG
#define DPRINTF(...) printf (__VA_ARGS__)
#else
#define DPRINTF(...) do {} while (0)
#endif
#ifndef _OPENMP
#define omp_get_num_threads() 1
#define omp_get_thread_num() 0
#endif

void
foo (int a, int b, int c, int d, int e, int f, int g, int h)
{
#ifdef DEBUG
#pragma omp single
  nitersv = 0;
#endif
#if 0
  #pragma omp for collapse(2) lastprivate (i, j, x)
#else
  #pragma omp single
#endif
  for (i = a; i < b; i += c)
for (j = d * i + e; j < f * i + g; j += h)
  {
x = i * 1024 + (j & 1023);
#ifdef DEBUG
nitersv++;
#endif
DPRINTF ("%d %d %d %d\n", i, j, x, omp_get_thread_num ());
  }
#ifdef DEBUG
  #pragma omp single
  DPRINTF ("niters = %d\n", nitersv);
#endif
}

void
bar (int a, int b, int c, int d, int e, int f, int g, int h)
{
  /* Proposed implementation of:
  #pragma omp for collapse(2) lastprivate (i, j, x)
  for (i = a; i < b; i += c)
for (j = d * i + e; j < f * i + g; j += h)  */

  /* OpenMP requires that ((f - d) * c) % h == 0
 and that either the initializer and condition expressions
 are outermost loop invariant, or have syntactic forms that can
 be represented as integral a1 * var-outer + a2 where var-outer
 is some outer loop iterator with compatible

Re: Push to my private branches is disallowed

[Segher Boessenkool]

On Tue, Jun 16, 2020 at 02:54:13PM +, Joseph Myers wrote:
> On Tue, 16 Jun 2020, Jonathan Wakely via Gcc wrote:
> 
> > I see no harm in rebasing public branches as long as nobody expects
> > otherwise.
> 
> And by design you *can* rebase user and vendor branches (but not those in 
> other namespaces).  The message about not being a fast-forward is just a 
> warning, not an error.

The "I will send X thousand email for this for no reason at all" *is*
an error.

IMNSHO, only release branches should send to gcc-cvs@.   That is trunk
and the usual release branches, and perhaps things that have *opted in*,
but nothing else.


Segher

Re: Push to my private branches is disallowed

[Segher Boessenkool]

Hi!

On Tue, Jun 16, 2020 at 02:09:37PM +0100, Jonathan Wakely wrote:
> I see no harm in rebasing public branches as long as nobody expects
> otherwise. A public branch on gcc.gnu.org under refs/heads that is
> being pulled by unknown persons and used in unknown forks for unknown
> purposes shouldn't be rebased, because you don't know who you're
> causing problems for by doing so.

You can cause *inconvenience* for people not expecting it.  But you
cause problems only for people who merge your branch.  Which they
shouldn't do at all, only ever where that is the agreed workflow (so
for GCC, that means never).

> But a personal branch like Segher's
> could disappear at any time. If we're going to discourage rebasing, we
> should also discourage deleting personal branches. But I don't see any
> benefit to that.

It is very simple to work with a branch that rebases.  First you always
fetch it with a +, which works fine on GCC, you should have something
like
fetch = +refs/users/*:refs/remotes/fsf/users/*
anyway.  And then you just rebase the branches which are on top of other
people's branches when those changed, on top of the new one.  This is
Git 101.

> If I create a branch refs/users/redi/work-in-progress for somebody

That needs to be refs/users/redi/heads/work-in-progress.  Sigh.

> else to look at and then delete it, do I have to remember never to
> create another branch using that name in future, in case somebody
> pulled the old branch before I deleted it?

Heh.  Well, they will still have their copy, and they can rewind history
if they need to as well.

> Randos on the internet aren't going to be basing work on those
> branches accidentally, they're not fetched by default so you have to
> make some non-trivial effort to even fetch them. If you do that, you
> should know you're not using an official GCC branch, but one that
> Segher can rebase or completely delete at any time.

It wouldn't even be *useful* *at all* otherwise.

(All "non-trivial work" that is needed is manually adding back the stuff
that was hidden, like
fetch = +refs/vendors/*:refs/remotes/fsf/vendors/*
fetch = +refs/users/*:refs/remotes/fsf/users/*
and adding
prune = true
and that is all that is needed -- and Git itself tells you if you forgot
the latter, even).

> I think only the owner of a personal branch should decide what
> workflow and rebasing policies apply to that branch.

There *is* no workflow requirement in general, just like not for trunk
or the release branches.  There are a few rules what can and cannot go
in a commit, and that is all.  And that is good.  On user branches
there are even fewer rules, which also is very good (I don't write
changelog entries before I send patches to gcc-patches@, generally.
This is less work, much higher quality changelog, and it forces you to
consider if you structured the patches and the patch series well).


Segher

Re-optimize instrumented GIMPLE code

[Shuai Wang via Gcc]

Hello,

Suppose I have changed certain if condition in the GIMPLE code (generated
by the `sanopt` pass) into the following format:

if (0 == 1)
{
   
}

Then, in order to completely remove this unnecessary if condition and the
guarded true branch, I want to leverage the dead code elimination
optimization of gcc. However, I just cannot figure out a way of doing so. I
use the following command to output the instrumented GIMPLE code:

gcc -fdump-tree-all -fplugin=./instrumentor.so -g -fsanitize=address test.c

And notice that the instrumented gimple code is right there in the
outputs: test.c.322t.instrumentor. Everything seems fine.

Anyone could shed some light on how to re-optimize (e.g., with deadcode
elimination or just use -O3 if possible) the instrumented GIMPLE code?
Thank you very much.

Shuai

Use gcov for line coverage info of GIMPLE code

[Shuai Wang via Gcc]

Hello,

I am aware of how to use gcov for c code line coverage collection. However,
currently I am working on a piece of GIMPLE code (did some instrumentation
on the GIMPLE code and therefore is more complex compared to the original C
code)l, and would like to collect the line coverage info of GIMPLE code
with gcov. Is it possible to do so? If so, could anyone shed some light on
this? Thank you very much.

Best,
Shuai

Re: Re-optimize instrumented GIMPLE code

[Martin Liška]

On 6/17/20 4:10 AM, Shuai Wang via Gcc wrote:

Hello,

Suppose I have changed certain if condition in the GIMPLE code (generated
by the `sanopt` pass) into the following format:


Hello.

What kind of instrumentation are you doing? Can you make the instrumentation
in a ASAN pass? Then you'll go through DCE.

Martin



if (0 == 1)
{

}

Then, in order to completely remove this unnecessary if condition and the
guarded true branch, I want to leverage the dead code elimination
optimization of gcc. However, I just cannot figure out a way of doing so. I
use the following command to output the instrumented GIMPLE code:

gcc -fdump-tree-all -fplugin=./instrumentor.so -g -fsanitize=address test.c

And notice that the instrumented gimple code is right there in the
outputs: test.c.322t.instrumentor. Everything seems fine.

Anyone could shed some light on how to re-optimize (e.g., with deadcode
elimination or just use -O3 if possible) the instrumented GIMPLE code?
Thank you very much.

Shuai

Re: Use gcov for line coverage info of GIMPLE code

[Martin Liška]

On 6/17/20 5:40 AM, Shuai Wang via Gcc wrote:

Hello,



Hello.

Right now, coverage information reports line execution of statements that
are present in the original source code.

Can you make a mapping of the instrumented code to statements that are present
in the original source code?

Martin


I am aware of how to use gcov for c code line coverage collection. However,
currently I am working on a piece of GIMPLE code (did some instrumentation
on the GIMPLE code and therefore is more complex compared to the original C
code)l, and would like to collect the line coverage info of GIMPLE code
with gcov. Is it possible to do so? If so, could anyone shed some light on
this? Thank you very much.

Best,
Shuai

Re: Use gcov for line coverage info of GIMPLE code

[Shuai Wang via Gcc]

Hello Martin,

The issue is that I want to count the coverage of "true/false" branches
taken in sanitizer's if conditions..

Best,
Shuai

On Wed, Jun 17, 2020 at 2:52 PM Martin Liška  wrote:

> On 6/17/20 5:40 AM, Shuai Wang via Gcc wrote:
> > Hello,
> >
>
> Hello.
>
> Right now, coverage information reports line execution of statements that
> are present in the original source code.
>
> Can you make a mapping of the instrumented code to statements that are
> present
> in the original source code?
>
> Martin
>
> > I am aware of how to use gcov for c code line coverage collection.
> However,
> > currently I am working on a piece of GIMPLE code (did some
> instrumentation
> > on the GIMPLE code and therefore is more complex compared to the
> original C
> > code)l, and would like to collect the line coverage info of GIMPLE code
> > with gcov. Is it possible to do so? If so, could anyone shed some light
> on
> > this? Thank you very much.
> >
> > Best,
> > Shuai
> >
>
>