This is the mail archive of the 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: [patch] for PR 27144


> > 	PR tree-optimization/27144
> > 	* tree-ssa-loop-niter.c (derive_constant_upper_bound): New function.
> > 	(record_estimate): Only record constant upper bound.
> > 	(infer_loop_bounds_from_undefined): Call
> > 	compute_estimated_nb_iterations just once.
> > 	(proved_non_wrapping_p): Renamed to ...
> > 	(n_of_executions_at_most): ... this.  Expect bound to be a constant.
> > 	(convert_step_widening, scev_probably_wraps_p): Call
> > 	n_of_executions_at_most instead of proved_non_wrapping_p.
> > 	(substitute_in_loop_info): Do not replace values in bounds.
> > 	* cfgloop.h (struct nb_iter_bound): Remove "additional" field.  Update
> > 	comments.
> >
> > 	* gcc.dg/tree-ssa/loop-16.c: New test.
> This is OK for mainline.  Thanks.
> Do you have any figures on what the change to fix PR 23434 has cost us
> in terms of performance? 

no.  Sebastian, did you do any measurements before commiting that patch?

The no-overflow analysis is basically only important on architectures
where sizeof(int) != sizeof (void *); we do regular benchmarks on
x86_64, so I believe we would notice any major drop in performance.


> I'm a tiny bit concerned that repeatedly
> disabling loop optimizations for correctness concerns over corner
> cases not originally considered in their design, may slowly be eroding
> GCC's performance.  My fears may be completely unfounded, but it would
> be nice to put an experimental figure on it rather than rely on guesses.
> But thanks for correcting these loop issues.  Correctness is the
> primary concern, and your efforts resolving these regression PRs is
> very much appreciated.

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