Re: Better handling for multi-word values?

[Bernd Schmidt <crux at pool dot informatik dot rwth-aachen dot de>]

> You mention the adddi case on a 32-bit host.  You may want to look
> into how I split these up in the 32-bit Sparc backend.  Essentially it
> starts with:
> 
> [(set (match_operand:DI 0 "register_operand" "=r")
>       (plus:DI (match_operand:DI 1 "arith_double_operand" "%r")
> 	       (match_operand:DI 2 "arith_double_operand" "rHI")))
>  (clobber (reg:CC 100))]
> 
> The clobber is emitted by the adddi expander on 32-bit Sparc.
> Then the forced split expansion gives something like:
> 
> [(parallel [(set (reg:CC_NOOV 100)
>                  (compare:CC_NOOV (plus:SI (match_dup 4)
>  					   (match_dup 5))
> 				  (const_int 0)))
>             (set (match_dup 3)
>                  (plus:SI (match_dup 4) (match_dup 5)))])
>  (set (match_dup 6)
>       (plus:SI (plus:SI (match_dup 7)
> 			(match_dup 8))
> 	       (ltu:SI (reg:CC_NOOV 100) (const_int 0))))]
> 
> I am pointing this out because if you can find a way to make your
> MULTIWORD mechanism express what I end up with above the adddi case
> will be quite cleanly solvable.

Well, with the MULTIWORD stuff you'd still have the option.  You could write
an adddi3 expander that builds something like the second pattern.  The operands
(regs 3/6 4/7, 5/8) would then be SImode pseudos instead of SImode subregs of
DImode pseudos, which is the advantage of this approach.  For simplicity it
would still be nice to be able to write the first pattern (match_operand will
match a MULTIWORD in that case), and have reload understand that it does not
need consecutive registers.
 
> I thought often about how the compiler could internally understand
> that the above is a way that adddi could be performed on a SImode word
> sized host.  This would involve adding code to check:
> 
> 1) Can the host add two SImode values and record the resulting
>    condition codes.
> 2) Can the host add two SImode values and also a carry condition
>    created by the previous CC setting instruction.
> 
> The Sparc split above shows data dependency completely, but the
> compiler really doesn't know what:
> 
> (ltu:SI (reg:CC_NOOV 100) (const_int 0))
> 
> means.  It knows that there are insns in the sparc MD file which match
> it and which operands are inputs and outputs, but nothing more.

What would you win by making this knowledge available to the compiler?

Bernd