This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Enabling rtl checking by default (was Re: [PATCH] Use movmem optab to attempt inline expansion of __builtin_memmove())


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?

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]