Re: [Patch] rtx_cost of SUBREG

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

> No problem.  If you're interested in the "gory" details, the failure
> goes like this.

Right, see my message to Ulrich.

> There were two possible resolutions, the first one I considered was
> to disallow this transformation if either operand of the AND was an
> IOR, i.e.
>
>
> 	if (GET_CODE (op0) == AND
> 	    && GET_CODE (XEXP (op0, 0)) != IOR
> 	    && GET_CODE (XEXP (op0, 1)) != IOR)
>
> the issue here is that its these inner operands being IOR of a constant
> that are typically the biggest winner of this transformation, allowing
> the outer IOR const_int to be combined with the inner IOR const_int.
>
> The alternative/combinatorics of searching for a common term in
> apply_distributive_law also seemed computationally too expensive, so
> my final (proposed) solution is to test whether the result of this
> transformation is cheaper than the original, which resolves the failure
> and should produce better code still.

I briefly experimented with the "computationally too expensive" solution this 
morning, i.e. allowing apply_distributive_law to look into nested levels of 
rtxs.  I almost immediately stopped when I realized how ugly this would be to 
write. :-)

> Finally, the reason the SUBREG change triggered this latent problem is
> another transformation in combine.c:
>
> 	y = gen_binary (AND, GET_MODE (x), XEXP (x, 0), GEN_INT (cval));
> 	if (rtx_cost (y, SET) < rtx_cost (x, SET))
> 	  x = y;
>
> where gen_binary is able to optimize AND by a constant into a SUBREG.
> Previously the COSTS_N_INSNS(1) meant that the SUBREG was as expensive
> as the AND of an immediate constant.  Now that SUBREGs are cheaper, we
> can eliminate the explicit operation.

You haven't answered my question so far: do you think it's unconditionally a 
win for every target (letting aside the MODES_TIEABLE_P thing)?

-- 
Eric Botcazou