This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Predicated execution
- To: law at cygnus dot com
- Subject: Re: Predicated execution
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Thu, 13 Jan 2000 10:45:52 +0000
- Cc: Michael Meissner <meissner at cygnus dot com>, gcc at gcc dot gnu dot org
- Cc: rearnsha at arm dot com
- Organization: ARM Ltd.
- Reply-To: rearnsha at arm dot com
> >
> > (if_then_else (~<cond>)
> > (set (reg) (mem (post_inc (<expr>)))
> > (const_int 0))
> >
> > and that the side effect does not occur if the condition is false? This
> > would be at variance with the normal definition of if_then_else where it
> > is my understanding that side effects occur whichever arm is true (this is
> > required so that reload can move sub-expressions out of the insn).
> I think this is a pretty key issue.
>
> It may be the case that we don't want to use IF_THEN_ELSE, but a new RTL
> code where the semantics of whether or not the true arm is evaluated if the
> predicate is false is explicit.
>
Some random thoughts...
How about a new type of insn, eg predicate_insn? You could then convert
an insn to being predicated by just changing the wrapper.
Eg
(predicate_insn 111 110 112 (set (foo) (bar))
(cond))
With this method you would probably also need predicate_call_insn and
predicate_jump_insn as well, so there might be a problem with where in the
insn the predicate operand was stored. So another idea might just be
(predicate_insn 111 110 112 (cond)
(insn 0 0 0 (set (foo) (bar))))
Though even with this care would be needed if you still need to detect
jump/call insns.
Feel free to shoot holes in this.
> > Hmm, how would the @pred work? Would we be able to match this based on an
> > attribute of the target insn? Or would there be some other way of
> > describing whether an insn can be safely predicated? I'm assuming that it
> > wouldn't be necessary to have a pattern like this for every insn in the
> > description that can be predicated (this would nearly double the size of
> > arm.md, which is already pretty large).
> The @pred is stuff rth has been working on. The basic idea is that the
> @pred will be an insn in and of itself and will be passed on to a recognizer
> to verify that it is a. a valid insn and b. it is valid for predication.
>
> The general idea is to have a small number of these predicated insns in the
> md file (in an ideal world, just one :-) instead of having to add a predicated
> version of each existing pattern.
I was hoping this was the case. Good.