On Tue, Oct 13, 2026 at 3:29 PM Martin Jambor <[email protected]> wrote:
>
> On Fri, Oct 09 2026, best xmg wrote:
> > Hi Martin,
> >
> > Sorry to bring you one more -- this is a follow-up about a part of
> > the original series that's still outstanding.
> >
> > I've attached v2-0007. It's what's left of old patch 5 now that
> > your ipa-cp part has been merged out and pushed.
> >
> > It passes a couple of 80-byte objects (wide_int/widest_int) by
> > reference instead of copying them. To check how often that
> > actually matters, I wrote a test file with lots of division, xor
> > and min/max comparisons -- those are exactly the operations that
> > reach these functions. I then traced a real build while compiling
> > it: tens of thousands of hits from that one file alone.
> >
> >> (The other bits in the patch need to be approved by someone else.)
> >
> > Do you know who I should ask, or what the right next step is?
>
> Either Andy or Andrew, who you have already CCed need to approve the
> changes in range-op.cc - but I don't think they can approve the rest, so
> I'd suggest to split the patch, send those changes separately again and
> CC them.
>
> I'd CC Richard Biener and/or Andrea Pinski on (a) patch(es) changing
> fold-const changes and tree-ssa-ccp. Again I'd send the changes
> separately for easier review. Note that I suspect both have currently
> too much stuff to review at the moment, so please be patient.
>
> I'm afraid I cannot help you more at this point.
>
> Martin
>
> >
> > Thanks,
> > Linden
> >
> >
> > On Tue, Sep 29, 2026 at 11:29 PM Martin Jambor <[email protected]> wrote:
> >>
> >> On Sat, Sep 26 2026, best xmg wrote:
> >> > Hi Martin,
> >> >
> >> > Thanks for the review. I split the ipa-cp part you suggested into a
> >> > new patch, attached. Please take a look.
> >> >
> >> > If anything is not going well, please tell me; I would really appreciate
> >> > it.
> >>
> >> I have committed the patch as fe236f5bef7.
> >>
> >> Thanks,
> >>
> >> Martin
> > From b6fbd35dab76a505c93471b28c2e086f7edc2bc0 Mon Sep 17 00:00:00 2001
> > From: linden <[email protected]>
> > Date: Sat, 26 Sep 2026 18:41:55 +1200
> > Subject: [PATCH 7/7] range-op, tree-ssa-ccp, fold-const: bind wide_int /
> > widest_int by reference
> >
> > wide_int and widest_int are 40-130 byte inline-buffer types; several
> > locals and by-value parameters across Ranger, CCP and fold-const copy
> > one where only reading is needed. Bind these by const reference
> > instead; no functional change. bit_value_binop's rotate arm keeps its
> > copy since it reassigns 'shift'.
> >
> > gcc/ChangeLog:
> > * range-op.cc (operator_div::wi_fold): Bind dividend_min/max and
> > divisor_min/max as const wide_int & rather than copying.
> > (operator_bitwise_xor::wi_fold): Likewise for new_lb.
> > * tree-ssa-ccp.cc (valid_lattice_transition): Take old_val and
> > new_val as const ccp_prop_value_t &.
> > (bit_value_binop): Bind 'shift' as const widest_int & in the
> > shift arm.
> > * fold-const.h (minmax_from_comparison, fold_cmp_float_cst_p):
> > Take widest_int / wide_int parameters by const reference.
> > * fold-const.cc (minmax_from_comparison, fold_cmp_float_cst_p):
> > Likewise.
> >
> > Signed-off-by: linden <[email protected]>
> > ---
> > gcc/fold-const.cc | 9 +++++----
> > gcc/fold-const.h | 8 ++++----
> > gcc/range-op.cc | 10 +++++-----
> > gcc/tree-ssa-ccp.cc | 5 +++--
> > 4 files changed, 17 insertions(+), 15 deletions(-)
> >
> > diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
> > index 4c4b535d440..8d6ab29b5e4 100644
> > --- a/gcc/fold-const.cc
> > +++ b/gcc/fold-const.cc
> > @@ -198,8 +198,8 @@ static tree fold_negate_expr (location_t, tree);
> > The form is "(exp0 CMP cst1) ? exp0 : cst2". */
> > tree_code
> > minmax_from_comparison (tree_code cmp, tree exp0,
> > - const widest_int cst1,
> > - const widest_int cst2)
> > + const widest_int &cst1,
> > + const widest_int &cst2)
> > {
> > if (cst1 == cst2)
> > {
> > @@ -7113,9 +7113,10 @@ fold_real_zero_addition_p (const_tree type,
> > const_tree arg,
> > due to truncation/rounding.
> > */
> > bool
> > -fold_cmp_float_cst_p (wide_int lo, wide_int hi, enum tree_code cmp,
> > +fold_cmp_float_cst_p (const wide_int &lo, const wide_int &hi,
> > + enum tree_code cmp,
> > const REAL_VALUE_TYPE *r, format_helper fmt,
> > - wide_int i, signop isign)
> > + const wide_int &i, signop isign)
> > {
> > REAL_VALUE_TYPE raw;
> > REAL_VALUE_TYPE rnd;
> > diff --git a/gcc/fold-const.h b/gcc/fold-const.h
> > index ab03bf0aa35..437d8ece021 100644
> > --- a/gcc/fold-const.h
> > +++ b/gcc/fold-const.h
> > @@ -173,11 +173,11 @@ extern bool integer_valued_real_p (tree, int = 0);
> >
> > extern bool fold_real_zero_addition_p (const_tree, const_tree, const_tree,
> > int);
> > -extern bool fold_cmp_float_cst_p (wide_int lo, wide_int hi,
> > +extern bool fold_cmp_float_cst_p (const wide_int &lo, const wide_int &hi,
> > enum tree_code cmp,
> > const REAL_VALUE_TYPE *r,
> > format_helper fmt,
> > - wide_int i, signop isign);
> > + const wide_int &i, signop isign);
> >
> > extern tree combine_comparisons (location_t, enum tree_code, enum
> > tree_code,
> > enum tree_code, tree, tree, tree);
> > @@ -253,8 +253,8 @@ extern tree fold_build_pointer_plus_hwi_loc (location_t
> > loc, tree ptr, HOST_WIDE
> > fold_build_pointer_plus_hwi_loc (UNKNOWN_LOCATION, p, o)
> >
> > extern tree_code minmax_from_comparison (tree_code, tree,
> > - const widest_int,
> > - const widest_int);
> > + const widest_int &,
> > + const widest_int &);
> > extern tree_code minmax_from_comparison (tree_code, tree, tree,
> > tree, tree);
> >
> > diff --git a/gcc/range-op.cc b/gcc/range-op.cc
> > index 350548951f4..3a0e6ed05d1 100644
> > --- a/gcc/range-op.cc
> > +++ b/gcc/range-op.cc
> > @@ -2585,10 +2585,10 @@ operator_div::wi_fold (irange &r, tree type,
> > const wide_int &lh_lb, const wide_int &lh_ub,
> > const wide_int &rh_lb, const wide_int &rh_ub) const
> > {
> > - const wide_int dividend_min = lh_lb;
> > - const wide_int dividend_max = lh_ub;
> > - const wide_int divisor_min = rh_lb;
> > - const wide_int divisor_max = rh_ub;
> > + const wide_int ÷nd_min = lh_lb;
> > + const wide_int ÷nd_max = lh_ub;
> > + const wide_int &divisor_min = rh_lb;
> > + const wide_int &divisor_max = rh_ub;
If we have a const reference alias why keep it and not replace it with the
also const reference RHS? As written it doesn't make much sense;
pushing down the declarations to where they are used might make the intent
more clear.
> > signop sign = TYPE_SIGN (type);
> > unsigned prec = TYPE_PRECISION (type);
> > wide_int extra_min, extra_max;
> > @@ -4288,7 +4288,7 @@ operator_bitwise_xor::wi_fold (irange &r, tree type,
> > = (wi::bit_and_not (mustbe_nonzero_lh, maybe_nonzero_rh)
> > | wi::bit_and_not (mustbe_nonzero_rh, maybe_nonzero_lh));
> > wide_int new_ub = ~result_zero_bits;
> > - wide_int new_lb = result_one_bits;
> > + const wide_int &new_lb = result_one_bits;
> >
> > // If the range has all positive or all negative values, the result
> > // is better than VARYING.
> > diff --git a/gcc/tree-ssa-ccp.cc b/gcc/tree-ssa-ccp.cc
> > index cc1da6540e3..1345a065194 100644
> > --- a/gcc/tree-ssa-ccp.cc
> > +++ b/gcc/tree-ssa-ccp.cc
> > @@ -433,7 +433,8 @@ canonicalize_value (ccp_prop_value_t *val)
> > /* Return whether the lattice transition is valid. */
> >
> > static bool
> > -valid_lattice_transition (ccp_prop_value_t old_val, ccp_prop_value_t
> > new_val)
> > +valid_lattice_transition (const ccp_prop_value_t &old_val,
> > + const ccp_prop_value_t &new_val)
> > {
> > /* Lattice transitions must always be monotonically increasing in
> > value. */
> > @@ -1626,7 +1627,7 @@ bit_value_binop (enum tree_code code, signop sgn, int
> > width,
> > is zero. */
> > if (r2mask == 0)
> > {
> > - widest_int shift = r2val;
> > + const widest_int &shift = r2val;
again - what's the point?
> > if (shift == 0)
> > {
> > *mask = r1mask;
> > --
> > 2.53.0
