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] expmed.c: Fix PR 23971 - slow synth_mult.


> > 	* expmed.c (alg_code): Add alg_impossible.
> > 	(alg_hash_entry): Add cost.
> > 	(synth_mult): Record alg_impossible in the hash table if
> > 	multiplication by a given integer is impossble within the
> > 	limit.  Speed up using alg_impossible.
> Cool!  This is OK for mainline.  Once its been there for a week
> or two without problems, you should consider asking the appropriate
> branch maintainers to consider backported versions.
> Thanks again for fixing this.  Additionally, we should probably
> investigate whether the multiply costs for the alpha backend are
> appropriately set, may be even reducing them artificially to limit
> the size of synthetic shift/add sequences we consider.
> I also suspect that there's an underlying issue with the way that
> the tree-ssa optimizers (including ivopts) are expanding large
> amounts of RTL to estimate the costs of certain transformations.

ivopts do rtl expansion once for each constant that is used in the
optimization (the results are cached).  This usually means that only
very small number of expansions is performed (5 for combine.i, and I
think will exceed 100 only on artificial testcases).  I never observed
any compile-time problems with this (except of course this particular
testcase, where ivopts produce a weird-looking constant -- inverse of
some normal-looking constant).

Nevertheless, ivopts could do with this much less precise knowledge,
if it turned out problematic.


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