Re: Truncate optimisation question

[Eric Botcazou <ebotcazou at adacore dot com>]

> Combine is asking simplify-rtx.c to truncate an addition to QImode
> and simplify-rtx.c is providing a reasonable representation of that.
> It's the representation we should use when matching against .md patterns,
> for example.  The problem is that combine doesn't want to keep the
> truncation in this case, but doesn't know that yet.

I disagree, I don't find it reasonable to turn an addition in SImode into an 
addition in QImode when the machine supports the former but not the latter.
I agree that it may help in some contexts, but then the transformation should 
be restricted to these contexts.

> Right, but the only complaint I know of is about its effect on combine.
> And my point is that that complaint isn't about combine failing to combine
> instructions per se.  It's that combine is failing to remove a redundant
> operation.  With the right input, the same rtl sequence could conceivably
> be generated on a CISC target like x86_64, since it defines all the required
> patterns (SImode addition, QI->SI zero extension, SImode comparison). It
> could also occur with a sequence that starts out as a QImode addition. So
> trying to make the simplification depend on CISCness seems like papering
> over the problem.

The problem is that this changes the combinations tried by the combiner in a 
way that is adverse to most RISC targets.  Sure, we could change all the 
affected back-ends but what's the point exactly?  What do we gain here?

Look for example at comment #4 in PR rtl-optimization/58295.

> If you think the patch was wrong or if you feel the fallout is too great
> then please feel free to revert it.

I think that the fallout is too great for RISC targets, yes, so I'm trying to 
find a reasonable compromise.

-- 
Eric Botcazou