Re: [PATCH v2 00/11] aarch64: Implement TImode comparisons

[Segher Boessenkool <segher@kernel.crashing.org>]

On Tue, Apr 07, 2020 at 05:50:38PM -0700, Richard Henderson wrote:
> On 4/7/20 4:58 PM, Segher Boessenkool wrote:
> >> I wonder if it would be helpful to have
> >>
> >>   (uoverflow_plus x y carry)
> >>   (soverflow_plus x y carry)
> >>
> >> etc.
> > 
> > Those have three operands, which is nasty to express.
> 
> How so?  It's a perfectly natural operation.

If you make a new code for it, sure.

You can also do

  C = ((unsigned tworeg)x + y + carry != (unsigned onereg)x + y + carry);

etc., but then in RTL of course; and then you find out that GCC can
simplify some but not all of those expressions, and it uses different
forms everywhere.

The trick is to find an expression that GCC can handle better.

> > On rs6000 we have the carry bit as a separate register (it really is
> > only one bit, XER[CA], but in GCC we model it as a separate register).
> > We handle it as a fixed register (there is only one, and saving and
> > restoring it is relatively expensive, so this worked out the best).
> 
> As for most platforms, more or less.

It's roughly equal how many have it in a separate reg vs. have it in the
condition reg, sure.  Somewhat fewer archs use GPRs for the carries.

> > Still, in the patterns (for insns like "adde") that take both a carry
> > input and have it as output, the expression for the carry output but
> > already the one for the GPR output become so unwieldy that nothing
> > can properly work with it.  So, in the end, I have all such insns that
> > take a carry input just clobber their carry output.  This works great!
> 
> Sure, right up until the point when you want to actually *use* that carry
> output.  Which is exactly what we're talking about here.

We only had two such cases:

a) Code like
  unsigned long f(unsigned long a, long b) { return a + (b > 0); }
we can do with only three insns (which GCC of course cannot derive by
itself, it needs extra patterns).  It now needs four insns (but GCC knows
to do that without using the carry at all).

b) It is useful for carry chains.  Which are very hard to express in C
and have GCC optimise it to what you want at all *anyway*.

> > Expressing the carry setting for insns that do not take a carry in is
> > much easier.  You get somewhat different patterns for various
> > immediate inputs, but that is all.
> 
> It's not horrible, but it's certainly verbose.  If we add a shorthand for that
> common operation, so much the better.

If GCC knows how to properly optimise with these new operators, you will
find you need (at least some of) those special cases again.

> I don't see why this new rtx code is any more difficult than ones that we have
> already.

It needs to be handled separately everywhere again.


Segher