Re: [PATCH 6/8] rs6000: Remove -m[no-]fold-gimple flag [PR103686]

[Segher Boessenkool <segher@kernel.crashing.org>]

On Fri, Jan 28, 2022 at 11:50:24AM -0600, Bill Schmidt wrote:
> The -m[no-]fold-gimple flag was really intended primarily for internal
> testing while implementing GIMPLE folding for rs6000 vector built-in
> functions.  It ended up leaking into other places, causing problems such
> as PR103686 identifies.  Let's remove it.

Okay.  BUT:

> gcc.target/powerpc/builtins-1.c was more problematic.  It was written in
> such a way as to be extremely fragile.  For this one, I rewrote the whole
> test in a different style, using individual functions to test each
> built-in function.  These same tests are also largely covered by
> builtins-1-be-folded.c and builtins-1-le-folded.c, so I chose to
> explicitly make this test -mbig for simplicity, and use -O2 for clean code
> generation.  I made some slight modifications to the expected instruction
> counts as a result, and tested on both 32- and 64-bit.

This made the testsuite part very hard to review again.  I gave up.

In the future, please do *one* logical change per patch.  That way at
least the patches are readable (they were not now, a lot of mixed-up
context).  So first a patch rewriting this testcase, and then a separate
patch that is the meat of *this* patch.

> Most instruction
> count tests now use the {\m ... \M} style, but I wasn't able to figure out
> how to get this right for vcmpequd. and vcmpgtud.  Using \. didn't do the
> trick, and I got tired of messing with it.  I can change those if you
> suggest the proper incantation for an opcode ending with a period.

{\madd\.} does the trick.  \.\M does not make any sense (a word cannot
end in a dot, it cannot contain one in the first place).  \M\. is valid,
but add\M\. is a bit silly: it is obvious the word ends there, there is
no need to assert that :-)

Okay for trunk like that.  Thanks!


Segher