This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: need for instruction attributes (ia64)
- From: "Jan Beulich" <JBeulich at novell dot com>
- To: <rth at redhat dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Wed, 12 Jan 2005 13:00:04 +0100
- Subject: Re: need for instruction attributes (ia64)
>>> Richard Henderson <rth@redhat.com> 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
would
>> need new infrastructure to support a double layer (or other method
of
>> 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
>
>as
>
> [(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
incompatible
>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
this.
Yes, I'm clear about the first part, and I was assuming/afraid of the
second.
>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.
Jan