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]

Re: Predicated execution


>   > 
>   > 	(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.



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