On Fri, Dec 16, 2022 at 12:37 PM Dimitrije Milosevic <dimitrije.milose...@syrmia.com> wrote: > > > Hi Richard, > > > The only documentation on complexity I find is > > > > int64_t cost; /* The runtime cost. */ > > unsigned complexity; /* The estimate of the complexity of the code for > > the computation (in no concrete units -- > > complexity field should be larger for more > > complex expressions and addressing modes). */ > > > > and complexity is used as tie-breaker only when cost is equal. Given that > > shouldn't unsupported addressing modes have higher complexity? I'll note > > that there's nothing "unsupported", each "unsupported" address computation > > is lowered into supported pieces. "unsupported" maybe means that > > "cost" isn't fully covered by address-cost and compensation stmts might > > be costed in quantities not fully compatible with that? > > Correct, that's what I was aiming for initially - before f9f69dd that was the > case, > "unsupported" addressing modes had higher complexities. > Also, that's what I meant by "unsupported" as well, thanks. > > > That said, "complexity" seems to only complicate things :/ We do have the > > tie-breaker on preferring less IVs. complexity was added in > > r0-85562-g6e8c65f6621fb0 as part of fixing PR34711. > > I agree that the complexity part is just (kind of) out there, not really > strongly > defined. I'm not sure how to feel about merging complexity into the cost part > of an address cost, though. > > > If it's really only about the "complexity" value then each > > compensation step should > > add to the complexity? > > That could be the way to go. Also worth verifying is that we compensate for > each case of an unsupported addressing mode.
Yes. Also given complexity is only a tie-breaker we should cost the compensation somehow, but then complexity doesn't look necessary ... Meh. > > Kind regards, > Dimitrije > > From: Richard Biener <richard.guent...@gmail.com> > Sent: Friday, December 16, 2022 10:58 AM > To: Dimitrije Milosevic <dimitrije.milose...@syrmia.com> > Cc: Jeff Law <jeffreya...@gmail.com>; gcc-patches@gcc.gnu.org > <gcc-patches@gcc.gnu.org>; Djordje Todorovic <djordje.todoro...@syrmia.com> > Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost > complexity. > > On Thu, Dec 15, 2022 at 4:26 PM Dimitrije Milosevic > <dimitrije.milose...@syrmia.com> wrote: > > > > Hi Richard, > > > > Sorry for the delayed response, I couldn't find the time to fully focus on > > this topic. > > > > > I'm not sure this is accurate but at least the cost of using an > > > unsupported > > > addressing mode should be at least that of the compensating code to > > > mangle it to a supported form. > > > > I'm pretty sure IVOPTS does not filter out candidates which aren't > > supported by > > the target architecture. It does, however, adjust the cost for a subset of > > those. > > The adjustment code modifies only the cost part of the address cost (which > > consists of a cost and a complexity). > > Having said this, I'd propose two approaches: > > 1. Cover all cases of unsupported addressing modes (if needed, I'm not > > entirely > > sure they aren't already covered), leaving complexity for > > unsupported > > addressing modes zero. > > The only documentation on complexity I find is > > int64_t cost; /* The runtime cost. */ > unsigned complexity; /* The estimate of the complexity of the code for > the computation (in no concrete units -- > complexity field should be larger for more > complex expressions and addressing modes). */ > > and complexity is used as tie-breaker only when cost is equal. Given that > shouldn't unsupported addressing modes have higher complexity? I'll note > that there's nothing "unsupported", each "unsupported" address computation > is lowered into supported pieces. "unsupported" maybe means that > "cost" isn't fully covered by address-cost and compensation stmts might > be costed in quantities not fully compatible with that? > > That said, "complexity" seems to only complicate things :/ We do have the > tie-breaker on prefering less IVs. complexity was added in > r0-85562-g6e8c65f6621fb0 as part of fixing PR34711. > > > 2. Revert the complexity calculation (which my initial patch does), > > leaving > > everything else as it is. > > 3. A combination of both - if the control path gets into the adjustment > > code, we > > use the reverted complexity calculation. > > If it's really only about the "complexity" value then each > compensation step should > add to the complexity? > > > I'd love to get feedback regarding this, so I could focus on a concrete > > approach. > > > > Kind regards, > > Dimitrije > > > > From: Richard Biener <richard.guent...@gmail.com> > > Sent: Monday, November 7, 2022 2:35 PM > > To: Dimitrije Milosevic <dimitrije.milose...@syrmia.com> > > Cc: Jeff Law <jeffreya...@gmail.com>; gcc-patches@gcc.gnu.org > > <gcc-patches@gcc.gnu.org>; Djordje Todorovic <djordje.todoro...@syrmia.com> > > Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost > > complexity. > > > > On Wed, Nov 2, 2022 at 9:40 AM Dimitrije Milosevic > > <dimitrije.milose...@syrmia.com> wrote: > > > > > > Hi Jeff, > > > > > > > This is exactly what I was trying to get to. If the addressing mode > > > > isn't supported, then we shouldn't be picking it as a candidate. If it > > > > is, then we've probably got a problem somewhere else in this code and > > > > this patch is likely papering over it. > > > > I'm not sure this is accurate but at least the cost of using an unsupported > > addressing mode should be at least that of the compensating code to > > mangle it to a supported form. > > > > > I'll take a deeper look into the candidate selection algorithm then. Will > > > get back to you. > > > > Thanks - as said the unfortunate situation is that both the original author > > and > > the one who did the last bigger reworks of the code are gone. > > > > Richard. > > > > > Regards, > > > Dimitrije > > > > > > ________________________________________ > > > From: Jeff Law <jeffreya...@gmail.com> > > > Sent: Tuesday, November 1, 2022 7:46 PM > > > To: Richard Biener; Dimitrije Milosevic > > > Cc: gcc-patches@gcc.gnu.org; Djordje Todorovic > > > Subject: Re: [PATCH 1/2] ivopts: Revert computation of address cost > > > complexity. > > > > > > > > > On 10/28/22 01:00, Richard Biener wrote: > > > > On Fri, Oct 28, 2022 at 8:43 AM Dimitrije Milosevic > > > > <dimitrije.milose...@syrmia.com> wrote: > > > >> Hi Jeff, > > > >> > > > >>> THe part I don't understand is, if you only have BASE+OFF, why does > > > >>> preventing the calculation of more complex addressing modes matter? > > > >>> ie, > > > >>> what's the point of computing the cost of something like base + off + > > > >>> scaled index when the target can't utilize it? > > > >> Well, the complexities of all addressing modes other than BASE + > > > >> OFFSET are > > > >> equal to 0. For targets like Mips, which only has BASE + OFFSET, it > > > >> would still > > > >> be more complex to use a candidate with BASE + INDEX << SCALE + OFFSET > > > >> than a candidate with BASE + INDEX, for example, as it has to > > > >> compensate > > > >> the lack of other addressing modes somehow. If complexities for both of > > > >> those are equal to 0, in cases where complexities decide which > > > >> candidate is > > > >> to be chosen, a more complex candidate may be picked. > > > > But something is wrong then - it shouldn't ever pick a candidate with > > > > an addressing > > > > mode that isn't supported? So you say that the cost of expressing > > > > 'BASE + INDEX << SCALE + OFFSET' as 'BASE + OFFSET' is not computed > > > > accurately? > > > > > > This is exactly what I was trying to get to. If the addressing mode > > > isn't supported, then we shouldn't be picking it as a candidate. If it > > > is, then we've probably got a problem somewhere else in this code and > > > this patch is likely papering over it. > > > > > > > > > Jeff > > >
