Re: Translation validation

[Krister Walfridsson <krister.walfridsson@gmail.com>]

On Wed, 14 Sep 2022, Richard Biener wrote:

> Note that the folding/peephole optimizations done early can be avoided
> when you separate opportunities in the source to multiple statements,
> like change
>
>  int a, b;
>  a = b + 1 - b;
>
> to
>
> a = b + 1;
> a = a - b;
>
> note that parts of the folding optimizations are shared between GENERIC
> and GIMPLE (those generated from match.pd), so those will be exercised.
> Fully exercising and verifying the fold-const.cc only optimizations which
> happen on GENERIC only is indeed going to be difficult.
>
> Another way to avoid some of the pre-SSA optimizations is to feed the
> plugin with input from the GIMPLE frontend.  Look at
> gcc/testsuite/gcc.dg/gimplefe-*.c for examples, IL can be dumped
> roughly in a format suitable as GIMPLE frontend input by dumping
> with -fdump-tree-<opt>-gimple (but note all type, global variable and function
> declarations are missing ...)

This does not help when trying to find wrong-code bugs by compiling random 
source code with plugin1.py.  :(

But it helps when writing tests for plugin2.py, so I wrote a simple script 
that extracts the first operand from match.pd simplify expressions and 
uses that to generate test cases. For example,

   (simplify
    (mult (abs@1 @0) @1)
    (mult @0 @0))

is generated as

   int __GIMPLE () f (int a0)
   {
     int _0;
     int a1;
     int _2;
     int _3;

     _2 = a0;
     a1 = __ABS _2;
     _3 = a1;
     _0 = a1 * _3;
     return _0;
   }

This is not an optimal way to find bugs as many of the simplify 
expressions have additional restrictions in the replacement part, so many 
of my generated functions fail to trigger optimizations...

This did not find any wrong-code bugs, but it found two cases where 
match.pd is missing TYPE_OVERFLOW_SANITIZED checks: PR 106990.

    /Krister