Re: need for instruction attributes (ia64)

["Jan Beulich" <JBeulich at novell dot com>]

>>> Richard Henderson <rth@redhat.com> 13.01.05 01:00:32 >>>
>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.

There's not too many of them, so manually creating variants would be
managable.

>> 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.

Perhaps (2) is the most reasonable thing, given that any construct
loosely like

	if (c)
		a = x ? y : z;
	else
		b = i ? j : k;

would benefit from .unc compares. (1) or (3) could be an option if e.g.
creating an additional mode (say UBImode) that doesn't have the
either-or semantics of BImode, but instead at-most-one ones, but only if
this is deemed not to be a generally useful approach (i.e. if one would
really only benefit special things like 128-bit math). What I don't like
about splitting late (even after reload_completed, not to mention after
the final if-convert) is that as I understand it the potential for
re-ordering (the resulting) instructions is much lower.

Now, that all said, would a basic (i.e. without the stuff discussed
here) patch to add TImode arithmetic still be acceptable for 4.0? As far
as I recall I didn't even try to submit the equivalent for x86-64 (after
having found time to rework the shifts on your request) because it
seemed too late.

Jan