Re: need for instruction attributes (ia64)

[Richard Henderson <rth at redhat dot com>]

On Wed, Jan 12, 2005 at 01:00:04PM +0100, Jan Beulich wrote:
> This doesn't look too nice, especially when wanting such constructs to
> be automatically derivable as they are for simple cond_exec-s.

How many compare patterns do you have?  I don't necessarily think
that we *need* something automatically derivable.  In any case, it's
an accurate representation of what the instruction actually does,
and something wrapped in a cond_exec would not be.

> As I was working on the TImode
> arithmetic splitters, I realized that these can't be conditionally
> executed, leading me into finding there's no support for .unc compares
> at all. Consider this (TImode add of rB:rA and rD:rC under control of an
> incoming predicate pA):
> 
> (pA)	add	rX = rA, rC
> (pA)	cmp.ltu.unc pB, pC = rX, rA
> (pB)	add	rY = rB, rD, 1
> (pC)	add	rY = rB, rD
> 
> Without writing explicit cond_exec alternative insns for every TImode
> insn (which I didn't even try yet, but surely should at some point to
> see if it would allow overcoming the problem at least explicitly), this
> is not possible in the current model, leading to numerous branches being
> generated instead.

Hum.  Well certainly this would be useful.  Given that no changes
along any of these lines will go into 4.0, I wonder what makes the
most sense.

(1) The simplest solution would be to add TImode arithmetic patterns,
    and arrange to not split them until after predication.  (There is
    not currently a variable to notice this condition.  We could either
    add one, or redesign the current non-scheme of N variables into a
    single variable that increments through some enumeration of states.)

    So you'd wind up with patterns that look like

	(parallel [(set (reg:ti r10) (add:ti (reg:ti r12) (reg:ti r14)))
                   (clobber (reg:bi p8))])

	or

	(cond_exec (ne (reg:bi p6) 0)
	  (parallel [(set (reg:ti r10) (add:ti (reg:ti r12) (reg:ti r14)))
		     (clobber (reg:bi p8))]))

    and then you'd have splitters that recognize both forms.

(2) Somewhat major modifications to the if-converter to know how to lower
    multiple levels of if's simultaneously, such that we know how to use
    cmp.unc right from the beginning.

(3) Derive lifetimes of predicates in the middle of if-conversion, and for
    locally generated and used predicates, know how to transform a compare
    into a predicated cmp.unc, updating the later uses of the predicates
    appropriately.

I dunno.  I really havn't given it much thought beyond that.  You're 
probably the first person to care about the performance of 128-bit 
arithmetic, and I don't know how often other forms of unconditional
compares would turn out to be useful.


r~