This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: need for instruction attributes (ia64)

>>> Richard Henderson <> 12.01.05 10:50:28 >>>
>On Wed, Jan 12, 2005 at 10:20:22AM +0100, Jan Beulich wrote:
>> ... for supporting .unc compares here (and perhaps elsewhere) one
>> need new infrastructure to support a double layer (or other method
>> combination) of cond_exec-s (depending on the predicate of the .unc
>> compare and its result predicate(s))... 
>Well, yes and no.  Comparisons being what they are, we wouldn't
>necessarily have to model a predicated cmp.unc as an instruction
>with a cond_exec applied.  Indeed, considering that a write always
>happens, I would counsul against it.  We could model 
>	(p1) cmplt.unc p2, p3 = r4, r5
>	[(set (reg:cci p2)
>	      (and:cci (lt:cci (reg:di r4) (reg:di r5))
>		       (reg:cci p1)))
>	 (set (reg:cci p3)
>	      (and:cci (ge:cci (reg:di r4) (reg:di r5))
>		       (reg:cci p1)))]

This doesn't look too nice, especially when wanting such constructs to
be automatically derivable as they are for simple cond_exec-s.

>That said, you'll also notice that we're only able to use predicates
>in pairs, which MUST be inverses of one another.  Which is
>with .unc compares.  There are a number of things that would have to
>change in the generic rtl optimizers that would be needed to fix

Yes, I'm clear about the first part, and I was assuming/afraid of the

>What's your ultimate goal?

Generate more reasonable code. 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.

Additionally I believe that .unc compares could help in various other
cases, too.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]