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
