> -----Original Message----- > From: Andrew MacLeod <amacl...@redhat.com> > Sent: Wednesday, February 22, 2023 4:42 PM > To: Tamar Christina <tamar.christ...@arm.com>; Richard Biener > <rguent...@suse.de>; Richard Sandiford <richard.sandif...@arm.com> > Cc: Tamar Christina via Gcc-patches <gcc-patches@gcc.gnu.org>; nd > <n...@arm.com>; j...@ventanamicro.com > Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask > by using new optabs [PR108583] > > > On 2/15/23 13:42, Andrew MacLeod wrote: > > > > On 2/15/23 12:50, Andrew MacLeod wrote: > >> > >> On 2/15/23 12:13, Tamar Christina wrote: > >>>> On 2/15/23 07:51, Tamar Christina wrote: > >> void > >> operator_plus::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 { > >> wi::overflow_type ov_lb, ov_ub; > >> signop s = TYPE_SIGN (type); > >> > >> // Do whatever wideint magic is required to do this adds in higher > >> precision > >> wide_int new_lb = wi::add (lh_lb, rh_lb, s, &ov_lb); > >> wide_int new_ub = wi::add (lh_ub, rh_ub, s, &ov_ub); > >> > >> r = int_range<2> (type, new_lb, new_ub); } > >> > >> > >> The operator needs to be registered, I've attached the skeleton for > >> it. you should just have to finish implementing wi_fold(). > >> > >> in theory :-) > >> > > You also mentioned earlier that some were tree codes, some were > > internal function calls? We have some initial support for built in > > functions, but I am not familiar with all the various forms they can > > take. We currently support CFN_ functions in > > > > gimple-range-op.cc, gimple_range_op_handler::maybe_builtin_call () > > > > Basically this is part of a "gimple_range_op_handler" wrapper for > > range-ops which can provide a range-ops class for stmts that don't map > > to a binary or unary form.. such as built in functions. > > > > If you get to the point where you need this for a builtin function, I > > can help you through that too. Although someone may have to also help > > me through what differentiates the different kinds of internal > > function :-) I presume they are all similar in some way. > > > > Andrew > > > Oh yeah, and in case you haven't figured it out on your own, you'll have > to remove WIDEN_MULT_EXPR from the range-ops init table. This > non-standard mechanism only gets checked if there is no standard > range-op table entry for the tree code :-P >
Hmm it looks like it'll work, but it keeps segfaulting in: bool range_op_handler::fold_range (vrange &r, tree type, const vrange &lh, const vrange &rh, relation_trio rel) const { gcc_checking_assert (m_valid); if (m_int) return m_int->fold_range (as_a <irange> (r), type, as_a <irange> (lh), as_a <irange> (rh), rel); while trying to call fold_range. But m_int is set to the right instance. Probably something I'm missing, I'll double check it all. Cheers, Tamar > Andrew > > Andrew