Re: [PATCH] rs6000: Don't split constant oprator when add, move to temp register for future optimization

[Alan Modra <amodra@gmail.com>]

On Fri, Apr 03, 2020 at 04:11:32PM -0500, Segher Boessenkool wrote:
> On Fri, Apr 03, 2020 at 10:43:49PM +1030, Alan Modra wrote:
> > Segher probably meant the part I'm working on and haven't posted yet,
> > fixing lots of problems with rs6000_rtx_costs.
> 
> I meant PR94393 in fact, but yeah, this is connected *everywhere* :-)
> 
> > One of the improvements
> > I'm aiming for is that we should be able to emit code that loads
> > constants from memory without following optimisation passes converting
> > the loads from memory to those long sequences of dependent instructions.
> 
> Yeah.  Looking forward to it :-)

I have a series of small patches already, the most significant so far
being the one that adds the following comment to rs6000_rtx_costs:

  "Calls from places like optabs.c:avoid_expensive_constant will come
   here with OUTER_CODE set to an operation such as AND with X being a
   CONST_INT or other CONSTANT_P type.  This will be compared against
   set_src_cost, where we'll come here with OUTER_CODE as SET and X
   the same constant.

   Calls from places like default_noce_conversion_profitable_p will
   come here via seq_cost and pass the pattern of a SET insn in X.
   The SET isn't handled here so *TOTAL will remain as
   COSTS_N_INSNS(1) multiplied by the number of words being set.
   Presuming the insn is valid and set_dest a reg, rs6000_rtx_costs
   will next see the set_src.  Continuing the example of an AND, this
   might be an AND of two other regs.  This AND should cost zero here
   since the insn cost has already been counted.  The overall cost
   value should be comparable to rs6000_insn_cost."

It pays to figure out what you need to do before doing anything.  :-)

Those two paragraphs will result in quite a few changes.  The first
one means that, for example, the rs6000_is_valid_and_mask test belongs
under case CONST_INT as
	  || (outer_code == AND
	      && rs6000_is_valid_and_mask (x, mode))
not under case AND.

The second paragraph says we are costing practically all operations
too highly.

I'm still in analysis mode, worried about whether gcc generates deep
rtl expressions to pass to rtx_cost.  I have a vague recollection of
seeing that years ago, but it looks like most places with anything
complex generate a sequence of insns and cost the sequence.  If we do
have expressions like (set (reg1) (and (plus (reg2) cst1) cst2)) then
rs6000_rtx_cost should recognise that AND as costing an extra insn.

-- 
Alan Modra
Australia Development Lab, IBM