Re: [PATCH 2/2] RISC-V/testsuite: Also verify if-conversion runs for pr105314.c

["Maciej W. Rozycki" <macro@embecosm.com>]

On Tue, 16 Jan 2024, Jeff Law wrote:

> >   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

 Thanks, I wasn't aware of this feature.

> >   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.

 It makes sense to me.

> 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.

 I'll be happy to add an RTL test case, also for my recent complementary 
cset-sext.c addition and maybe other if-conversion pieces recently added.  
I think that does not preclude arming pr105314.c with RTL scanning though.

  Maciej