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
