This is the mail archive of the
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 09:05:43 +0100
- Subject: Re: need for instruction attributes (ia64)
>> - whether define_split (and define_insn_and_split if all of its
>> alternatives split) should generally have a predicable attribute
>> value no ...
>Splits don't have attributes.
How would I get the result of a splitter to be conditionally executed,
then? I namely realized that there is, except for a very special case,
no support for unc-type compares. If a splitter would have some of its
resulting insns cond_exec-ed depending on a predicate it generates
itself, and if the former was generated through a cmp.XX.unc, all the
cond_exec-s would remain valid (in that none of them would get
executed), allowing the elimination of quite a number of branches.
>> ... but the split code does not appear to ever get
>> conditionalized, so the patterns seems simply useless, making the
>> compiler bigger and perhaps slower)
>Nor do they get duplicated for predication.
What do these odd "(%Jn) #" things in insn-output.c then originate
from? I suppose they come from define_insn_and_split/define_insn where
the pattern is just "#", and to prevent those from being generated one
could either give all of them a predicable attribute with value 0 or
have the generator code not duplicate these for cond_exec in the first