On Wed, Nov 11, 2020 at 08:53:56PM +0100, Philipp Tomsich wrote:
> > On 11/11/20 3:55 AM, Jakub Jelinek via Gcc-patches wrote:
> > > On Wed, Nov 11, 2020 at 11:43:34AM +0100, Philipp Tomsich wrote:
> > >> The patch addresses this by disallowing that rule, if an exact
> > >> power-of-2 is
> > >> seen as C1. The reason why I would prefer to have this canonicalised the
> > >> same way the (X & C1) * C2 is canonicalised, is that cleaning this up
> > >> during
> > >> combine is more difficult on some architectures that require multiple
> > >> insns
> > >> to represent the shifted constant (i.e. C1 << C2).
> > > It is bad to have many exceptions for the canonicalization
> > > and it is unclear why exactly these were chosen, and it doesn't really
> > > deal
> > > with say:
> > > (x & 0xabcdef12ULL) << 13
> > > being less expensive on some targets than
> > > (x << 13) & (0xabcdef12ULL << 13).
> > > (x & 0x7ffff) << 3 vs. (x << 3) & 0x3ffff8 on the other side is a wash on
> > > many targets.
> > > As I said, it is better to decide which one is better before or during
> > > expansion based on target costs, sure, combine can't catch everything.
> >
> > I think Jakub is hitting a key point here. Gimple should canonicalize
> > on what is simpler from a gimple standpoint, not what is better for some
> > set of targets. Target dependencies like this shouldn't be introduced
> > until expansion time.
>
> The simplification that distributes the shift (i.e. the one that Jakub
> referred
> to as fighting the new rule) is also run after GIMPLE has been expanded to
> RTX. In my understanding, this still implies that even if we have a
> cost-aware
> expansion, this existing rule will nonetheless distribute the shift.
At the RTL level, such simplifications should not happen if it is
against costs (e.g. combine but various other passes too check costs and
punt if the new code would be more costly than the old one).
Jakub
