Re: Re-optimize instrumented GIMPLE code

[Shuai Wang via Gcc]

Dear Martin,

Thanks for the kind reply. I don't have a strong preference between `asan0`
vs. `sanopt`. But I note that I am primarily working on sanitizer enabled
code, where I can only find some .ASAN_CHECK function calls in `asan0`, but
those function calls seem have been inlined in `sanopt`. In other words, I
can constantly find the following pattern:

 *if (_44 != 0)*
goto ; [0.05%]
  else
goto ; [99.95%]

   :
  __builtin___asan_report_load4 (_34);

The marked if condition is where my analysis and instrumentation starts
from. If I go with `asan0`, then I just cannot find it (it's somewhat
wrapped within .ASAN_CHECK).

Best,
Shuai

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

> 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 8:57 AM, Shuai Wang wrote:

Hello Martin,

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


I see. Well, you may abuse a bit the existing:

   -fsanitize-coverage=trace-pc
   Enable coverage-guided fuzzing code instrumentation.  Inserts a call to 
"__sanitizer_cov_trace_pc" into every basic block.

And put corresponding builtins to the true/false branches in the instrumented 
code.

Martin



Best,
Shuai

On Wed, Jun 17, 2020 at 2:52 PM Martin Liška mailto:mli...@suse.cz>> 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
 >

Re: Re-optimize instrumented GIMPLE code

[Martin Liška]

On 6/17/20 9:00 AM, Shuai Wang wrote:

Dear Martin,

Thanks for the kind reply.


Hey.

You're welcome.


I don't have a strong preference between `asan0` vs. `sanopt`. But I note that 
I am primarily working on sanitizer enabled code, where I can only find some 
.ASAN_CHECK function calls in `asan0`, but those function calls seem have been 
inlined in `sanopt`.


Note that .ASAN_CHECK is not inlined but "instrumented". The function is about 
taking look in the shadow memory
and checking that a memory write is valid.


In other words, I can constantly find the following pattern:

*if (_44 != 0)*
     goto ; [0.05%]
   else
     goto ; [99.95%]

    :
   __builtin___asan_report_load4 (_34);

The marked if condition is where my analysis and instrumentation starts from. 
If I go with `asan0`, then I just cannot find it (it's somewhat wrapped within 
.ASAN_CHECK).


Can you please explain which ASAN_CHECKs are you trying to modify? We can 
probably find a proper
place where to implement your plugin-in functionality.

Martin



Best,
Shuai

On Wed, Jun 17, 2020 at 2:49 PM Martin Liška mailto:mli...@suse.cz>> wrote:

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: Re-optimize instrumented GIMPLE code

[Shuai Wang via Gcc]

Dear Martin,

Thanks for the information. I am tentatively experimenting some random
gadgets; given the critical if condition belonging to each sanitizer check,
i will do some data flow analysis and then decide whether to remove that
check or not (done). If so, I will rewrite that if condition into always
false (done), and hope I can re-launch the dead code elimination pass of
GCC to automatically remove that particular sanitizer check (and the if
condition).

This is just some random hacks, so probably far from the adoption stage...
If it does, then i will be glad to reach out and discuss more on the
details (although i am not sure how it goes)...

Shuai



On Wed, Jun 17, 2020 at 3:05 PM Martin Liška  wrote:

> On 6/17/20 9:00 AM, Shuai Wang wrote:
> > Dear Martin,
> >
> > Thanks for the kind reply.
>
> Hey.
>
> You're welcome.
>
> > I don't have a strong preference between `asan0` vs. `sanopt`. But I
> note that I am primarily working on sanitizer enabled code, where I can
> only find some .ASAN_CHECK function calls in `asan0`, but those function
> calls seem have been inlined in `sanopt`.
>
> Note that .ASAN_CHECK is not inlined but "instrumented". The function is
> about taking look in the shadow memory
> and checking that a memory write is valid.
>
> > In other words, I can constantly find the following pattern:
> >
> > *if (_44 != 0)*
> >  goto ; [0.05%]
> >else
> >  goto ; [99.95%]
> >
> > :
> >__builtin___asan_report_load4 (_34);
> >
> > The marked if condition is where my analysis and instrumentation starts
> from. If I go with `asan0`, then I just cannot find it (it's somewhat
> wrapped within .ASAN_CHECK).
>
> Can you please explain which ASAN_CHECKs are you trying to modify? We can
> probably find a proper
> place where to implement your plugin-in functionality.
>
> Martin
>
> >
> > Best,
> > Shuai
> >
> > On Wed, Jun 17, 2020 at 2:49 PM Martin Liška  mli...@suse.cz>> wrote:
> >
> > 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: Re-optimize instrumented GIMPLE code

[Martin Liška]

On 6/17/20 9:10 AM, Shuai Wang wrote:

Dear Martin,

Thanks for the information. I am tentatively experimenting some random gadgets; 
given the critical if condition belonging to each sanitizer check, i will do 
some data flow analysis and then decide whether to remove that check or not 
(done). If so, I will rewrite that if condition into always false (done), and 
hope I can re-launch the dead code elimination pass of GCC to automatically 
remove that particular sanitizer check (and the if condition).


That seems very close to what we do in maybe_optimize_asan_check_ifn 
(sanopt.c). There we make a decision
if a ASAN_CHECK should be expanded or optimized out. You may implement your 
functionality to the place.



This is just some random hacks, so probably far from the adoption stage... If 
it does, then i will be glad to reach out and discuss more on the details 
(although i am not sure how it goes)...


I see.
Note that I'm not a plug-in guy, but more a GCC developer. That's why I prefer 
direct modifications
to the compiler rather than offloading work to a plug-in ;)

Martin



Shuai



On Wed, Jun 17, 2020 at 3:05 PM Martin Liška mailto:mli...@suse.cz>> wrote:

On 6/17/20 9:00 AM, Shuai Wang wrote:
 > Dear Martin,
 >
 > Thanks for the kind reply.

Hey.

You're welcome.

 > I don't have a strong preference between `asan0` vs. `sanopt`. But I 
note that I am primarily working on sanitizer enabled code, where I can only find 
some .ASAN_CHECK function calls in `asan0`, but those function calls seem have 
been inlined in `sanopt`.

Note that .ASAN_CHECK is not inlined but "instrumented". The function is 
about taking look in the shadow memory
and checking that a memory write is valid.

 > In other words, I can constantly find the following pattern:
 >
 > *if (_44 != 0)*
 >      goto ; [0.05%]
 >    else
 >      goto ; [99.95%]
 >
 >     :
 >    __builtin___asan_report_load4 (_34);
 >
 > The marked if condition is where my analysis and instrumentation starts 
from. If I go with `asan0`, then I just cannot find it (it's somewhat wrapped 
within .ASAN_CHECK).

Can you please explain which ASAN_CHECKs are you trying to modify? We can 
probably find a proper
place where to implement your plugin-in functionality.

Martin

 >
 > Best,
 > Shuai
 >
 > On Wed, Jun 17, 2020 at 2:49 PM Martin Liška mailto:mli...@suse.cz> 
>> wrote:
 >
 >     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: Re-optimize instrumented GIMPLE code

[Richard Biener via Gcc]

On Wed, Jun 17, 2020 at 4:11 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:
>
> 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:

A simple CFG cleanup would get rid of the above, if you insert a pass
make sure to return TODO_cfg_cleanup from it.

> 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: RFC/RFH - proof of concept for GCC OpenMP 5.0 non-rectangular worksharing-loop implementation

[Richard Biener]

On Tue, 16 Jun 2020, Jakub Jelinek wrote:

> 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)  */
> 
>   /* Open

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

[Jakub Jelinek via Gcc]

On Wed, Jun 17, 2020 at 02:29:40PM +0200, Richard Biener wrote:
> So this remembers me of the loop scalarization pass Sebastian once
> implemented - that is, with the above constraints it looks like we
> can do the actual collapsing, replacing collapsed loops with a new
> one with a canonical IV from 0 to N (thus another rectangular one).
> The old IVs would be either directly computed from that N
> (but that requires costly modulo) or be derived IVs that would
> not be affine (because they are "wrapping", aka reset).

For rectangular loop nests it is something that omp-expand.c does
already since June 2008, the major difference is that it is far easier
to rectangular loops, total number of iterations of the loop nest is
a product of number of iterations in each associated loop and
to determine the user IVs from the collapsed 0 to N can be done using
modulo.

The comments in omp-expand.c describe it:
   zero3 = N32 c3 N31;
   count3 = (N32 - N31) /[cl] STEP3;
   zero2 = N22 c2 N21;
   count2 = (N22 - N21) /[cl] STEP2;
   zero1 = N12 c1 N11;
   count1 = (N12 - N11) /[cl] STEP1;
   zero = zero3 || zero2 || zero1;
   count = count1 * count2 * count3;
   if (__builtin_expect(zero, false)) goto zero_iter_bb;
and
/* Helper function for expand_omp_{for_*,simd}.  Generate code like:
T = V;
V3 = N31 + (T % count3) * STEP3;
T = T / count3;
V2 = N21 + (T % count2) * STEP2;
T = T / count2;
V1 = N11 + T * STEP1;
   if this loop doesn't have an inner loop construct combined with it.
   If it does have an inner loop construct combined with it and the
   iteration count isn't known constant, store values from counts array
   into its _looptemp_ temporaries instead.  */

What I need now is just extend this to the non-rectangular loops
and that involves Summæ Potestatum for the count number of iterations and
finding roots of quadratic/cubic etc. equations for the second step.

> Are the loops required to be perfectly nesting?  At least those
> that collapse?

Before OpenMP 5.0 they are required to be perfectly nested, 5.0 essentially
allows some non-perfect nesting but says that it is unspecified how many
times the extra code that makes the loop not perfectly nested is executed,
so it should be possible to e.g. move it into the innermost loop body if
needed, or perform just once for the outer loop iterator etc.

Anyway, here is the updated proof of concept which should use n*(n+1)/2
and isqrt even if the inner loop has no iterations for some values of the
outer one.

CCing also Sebastian if he has some ideas.

Jakub
/* 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 type and a1 and a2 are
 integral expressions (and have compatible type too), which are outermost
 loop invariant.  Comparisons can be <, <=, >, >= or != but in the last
 case the step is required to be compile time constant so that one
 can determine iteration direction and f

Re: AVR CC0 transition

[John Paul Adrian Glaubitz]

Hi!

On 5/25/20 2:56 PM, John Paul Adrian Glaubitz wrote:
>> I'm thinking about attempting to do the CC0 transition for the
>> AVR port in my spare time.  I've read the CC0Transition gcc wiki
>> page, and as the AVR ISA does not have non-condition-code
>> clobbering arithmetic instructions, concluded that I'd have to
>> follow the steps outlined for case #2.
> 
> If you are working on it, it might be a good idea to log in to 
> Bountysource.com
> and mark the issue as being worked on [1], so you can get the bounty in case
> the conversion has been successful.

Important update: Bountysource has announced that they will let bounties expire 
in
the future if not claimed after two years [1]. So, unless someone claims the 
money
with the next two years, the money will be gone.

It would therefore be good for anyone working on the AVR MODE_CC conversion 
(Senthil?)
that they submit a claim for this bounty [2] after the patches to convert the 
AVR backend
have been accepted upstream.

It would be a shame if the money would be taken by Bountysource in the end. If 
the
developer who submits the claim, cannot take the money for legal reasons (i.e. 
because
worked on it during company time), I would suggest donating the money to a good 
cause.

The same applies to the campaign for the VAX backend [3].

Adrian

> [1] https://news.ycombinator.com/item?id=23551098
> [2] 
> https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
> [3] 
> https://www.bountysource.com/issues/91495157-vax-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[Philippe Clauss]

Dear Jakub and all,

When handling loop nests whose loop bounds are linearly depending on 
outer loop iterators and size parameters, it is known that the number of 
iterations is a specific kind of polynomial of the size parameters, also 
called an Ehrhart polynomial.


I have recently published a paper at IPDPS 2017 where the collapsing of 
non-rectangular parallel loops is solved by inverting Ehrhart 
polynomials. Benchmarks using OpenMP are exhibited. It uses floating 
point computations to compute roots of such polynomials which are then 
evaluated once per thread when running the parallel loop which results 
from non-rectangular collapsed loops, in order for each thread to start 
with correct iterators values.


The necessary computations can be handled with ISL, but an additional 
computer algebra system is required to solve polynomial equations (I use 
Maxima).


Please have a look at the IPDPS paper, freely available here: 
https://www.researchgate.net/publication/317369488_Automatic_Collapsing_of_Non-Rectangular_Loops


Ehrhart polynomials for parametrized loop trip counts have been 
introduced in this paper: 
https://www.researchgate.net/publication/221235615_Counting_Solutions_to_Linear_and_Nonlinear_Constraints_Through_Ehrhart_Polynomials_Applications_to_Analyze_and_Transform_Scientific_Programs


I would be happy to discuss this topic.

Best regards,
Philippe

Re: Re-optimize instrumented GIMPLE code

[Jeff Law via Gcc]

On Wed, 2020-06-17 at 15:10 +0800, Shuai Wang via Gcc wrote:
> Dear Martin,
> 
> Thanks for the information. I am tentatively experimenting some random
> gadgets; given the critical if condition belonging to each sanitizer check,
> i will do some data flow analysis and then decide whether to remove that
> check or not (done). If so, I will rewrite that if condition into always
> false (done), and hope I can re-launch the dead code elimination pass of
> GCC to automatically remove that particular sanitizer check (and the if
> condition).
> 
> This is just some random hacks, so probably far from the adoption stage...
> If it does, then i will be glad to reach out and discuss more on the
> details (although i am not sure how it goes)...
If you just ensure that the cfg cleanups are done when the pass is done the 
right things will just happen.  CFG cleanups are typically signaled by 
returning TODO_cleanup_cfg at the end of the pass.  There should be numerous 
examples throughout the GCC source code.

jeff

Re: Use gcov for line coverage info of GIMPLE code

[Shuai Wang via Gcc]

Hey Martin,

Thanks a lot for the info. I tried to play with __sanitizer_cov_trace_pc
but still quite confused on whether it can instrument extra basic blocks
introduced by ASAN. Let me present the GIMPLE code for your reference:

Given the following C code:

int main(int argc ,char **argv)
{
int stack_array[100];
stack_array[1] = 100;
int c1 = stack_array[argc + 12];  <--- ASAN
if (argc > 12){
int c3 = stack_array[argc + 17];   <--- ASAN
}
}

I use the following way of compiling:

trace.o: trace.c
$(CC) -c -o $@ $<

test.o: test.c
$(CC) *-fdump-tree-all* -g -O0 -fsanitize=address  -c -o $@ $<
$(CFLAGS) $(LIBS)

test : $(OBJ)
$(CC) -g -O0 -fsanitize=address -o $@ $^ $(CFLAGS) $(LIBS)


I note in the dumped IR code: test.c.223t.sanopt, I do find
`__builtin___sanitizer_cov_trace_pc` in the if condition of the original C
code; however, there was no __builtin___sanitizer_cov_trace_pc in the if
branches corresponding to sanitizer checks:

if (_32 != 0)
 goto ; [0.04%]
else
 goto ; [99.96%]

 [0.00%]:
__builtin___asan_report_store4 (_22);

 [0.00%]:
stack_array[1] = 100;
_1 = argc_6(D) + 12;
_17 = &stack_array[_1];
_33 = (unsigned long) _17;

It seems that -fsanitize-coverage=trace-pc still happens
before -fsanitize=address. Is it how it's supposed to be? Thanks a lot!

Best,
Shuai

On Wed, Jun 17, 2020 at 3:03 PM Martin Liška  wrote:

> On 6/17/20 8:57 AM, Shuai Wang wrote:
> > Hello Martin,
> >
> > The issue is that I want to count the coverage of "true/false" branches
> taken in sanitizer's if conditions..
>
> I see. Well, you may abuse a bit the existing:
>
> -fsanitize-coverage=trace-pc
> Enable coverage-guided fuzzing code instrumentation.  Inserts
> a call to "__sanitizer_cov_trace_pc" into every basic block.
>
> And put corresponding builtins to the true/false branches in the
> instrumented code.
>
> Martin
>
> >
> > Best,
> > Shuai
> >
> > On Wed, Jun 17, 2020 at 2:52 PM Martin Liška  mli...@suse.cz>> 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
> >  >
> >
>
>