This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question about dump_printf/dump_printf_loc
- From: "Richard Biener via gcc" <gcc at gcc dot gnu dot org>
- To: sellcey at cavium dot com
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 8 May 2017 09:09:21 +0200
- Subject: Re: Question about dump_printf/dump_printf_loc
- Authentication-results: sourceware.org; auth=none
- References: <201705052237.v45Mbq6G008507@sellcey-dt.caveonetworks.com>
- Reply-to: Richard Biener <richard dot guenther at gmail dot com>
On Sat, May 6, 2017 at 12:37 AM, Steve Ellcey <sellcey@cavium.com> wrote:
> I have a simple question about dump_printf and dump_printf_loc. I notice
> that most (all?) of the uses of these function are of the form:
>
> if (dump_enabled_p ())
> dump_printf_loc (MSG_*, ......);
>
> Since dump_enabled_p() is just checking to see if dump_file or alt_dump_file
> is set and since dump_printf_loc has checks for these as well, is there
> any reason why we shouldn't or couldn't just use:
>
> dump_printf_loc (MSG_*, ......);
>
> with out the call to dump_enabled_p and have the dump function do nothing
> when there is no dump file set? I suppose the first version would have
> some performance advantage since dump_enabled_p is an inlined function,
> but is that enough of a reason to do it? The second version seems like
> it would look cleaner in the code where we are making these calls.
The purpose of dump_enabled_p () is to save compile-time for the common case,
esp. when guarding multiple dump_* calls. But also for the single-called case.
You could try improve things by having inline wrappers for all dump_* cases that
inline a dump_enabled_p () call but that would be somewhat gross.
Richard.
> Steve Ellcey
> sellcey@cavium.com