On Wed, Nov 11, 2020 at 09:04:28PM +0100, Philipp Tomsich wrote:
> On Wed, 11 Nov 2020 at 20:59, Jakub Jelinek <ja...@redhat.com> wrote:
> > >
> > > 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).
>
> I agree.
> Let me go back and investigate if the cost-model is misreading things, before
> we
> continue the discussion.
If it is on some targets, surely it should be fixed.
E.g. x86_64 certainly has different costs for constants that fit into
instruction's immediates and for constants that need to be loaded into
registers first.
I know various other targets have much more complex sequences to compute
certain constants in registers though.
sparc costs surprise me:
case CONST_INT:
if (SMALL_INT (x))
*total = 0;
else
*total = 2;
because for the else I'd have expect better analysis of the constant to see
how many instructions are needed for it (I think maximum is 6).
Jakub
