On 1/12/24 06:59, Maciej W. Rozycki wrote:
On Fri, 12 Jan 2024, Andrew Pinski wrote:
Verify that if-conversion succeeded through noce_try_store_flag_mask, as
per PR rtl-optimization/105314, tightening the test case and making it
explicit.
gcc/testsuite/
* gcc.target/riscv/pr105314.c: Scan the RTL "ce1" pass too.
I have an objection for this, if we are checking the RTL pass and not
overall code generation, then maybe we change the testcase so that it
is a RTL testcase instead.
It's not clear to me what you mean by an "RTL testcase", i.e. how you'd
see the testcase changed (or an additional one produced instead) and why,
please elaborate. Right now we verify that branches are absent from
output, but not how that happens.
What I'm guessing Andrew is suggesting is the testcase be adjusted so
that its source is RTL rather than C. With that framework you can skip
most of the pipeline and make the test more stable if something changes
earlier in the pipeline.
There aren't a lot of great examples of this and the RTL parser is
probably less stable than the gimple parser. But if you look in
gcc.dg/rtl you should see examples.
In theory you can take the RTL dump from a pass, massage it and feed it
back into the compiler. Perhaps a good example is rtl/x86_64/ira.c
Especially when there might be improvements going into GCC 15
specifically targeting ifcvt on the gimple level (I am planning on
doing some).
How are the improvements going to affect the testcase?
If they make it no longer relevant (in which case a replacement testcase
for the new arrangement will be needed) or require updates, then I think
it's an expected situation: one of the purposes of the testsuite is to
make sure we're in control and understand what the consequences of changes
made are. It's not that the testsuite is cast in stone and not expected
to change.
I.e. if we expect noce_try_store_flag_mask no longer to trigger, then
we'll see that in the test results (good!) and we can update the relevant
test case(s). e.g. by reversing the pass criteria so that we're still in
control.
I think Andrew's point is that we can still test that the pass does what
we want when presented with RTL in a particular form and isolate the
pass from depending on prior passes in the pipeline either creating or
not destroying the particular form we want to ensure is properly handled.
I don't have a strong opinion on this. I certainly see Andrew's point,
but it's also the case that if some work earlier in the RTL or gimple
pipeline comes along and compromises the test, then we'd see the failure
and deal with it. It's pretty standard procedure.
Jeff
