This is the mail archive of the gcc@gcc.gnu.org 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)


>> - whether define_split (and define_insn_and_split if all of its
>> alternatives split) should generally have a predicable attribute
with
>> 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
place.

Jan


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