Jakub Jelinek <ja...@redhat.com> writes: > On Thu, Oct 03, 2019 at 11:14:25AM +0100, Richard Sandiford wrote: >> Confusingly, it needs to be --enable-checking=yes,extra,rtl for rtl >> to be a pure addition to the default. >> >> I guess it's time for a new entry in the semi-regular series >> "should rtl checking be enabled by default for development builds?" :-) >> Is it realy so expensive that it needs to be off by default? And do >> we gain much from having it off by default when many developers just >> enable it anyway? The status quo seems like an unnecessary trap to me. >> >> "rtl" checking is an everyday checking option that regularly finds >> problems, unlike say "df" and "fold" (which very rarely find problems) >> and "gcac" (which definitely isn't an everyday option). > > rtl checking can be everyday checking option (it is e.g. for me), but I'm > not sure if it needs to be forced onto all the developers, e.g. those > working on FEs or GIMPLE will only very rarely trigger some RTL checking > failure with their changes, and it is quite expensive (mainly, the insn*.c > sources when they contain RTL checking take much longer to compile). > Perhaps we should be just recommending --enable-checking=yes,extra,rtl for > those that test RTL/backend patches?
Maybe, but the problem is that someone who doesn't work on RTL/backend patches very often might not be aware of or think about adding the option specially. We'd also benefit if as many CI builds as possible enabled rtl checking. So IMO the default should be --enable-checking=yes,extra,rtl so that we get better coverage. Then people who want faster bootstrap/test times can use --enable-checking=yes,extra if they "know" it's safe for the work they're doing (with that being a recognised thing to do -- it's OK not to catch latent rtl problems). Richard
