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


On Wed, Jan 12, 2000 at 11:22:44AM +0000, Richard Earnshaw wrote:
> 
> 	(set (pc) (if_then_else (<cond>)
> 		   (label_ref <L>)
> 		   (pc)))
> 
> 	(set (reg) (mem (post_inc (<expr>))))
> 
> 	(code_label <L>)
> 
> can be written as
> 
> 	(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?

Yes.

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

Reload doesn't move arbitrary sub-expressions out of the insn,
only operands.  But you do have a point wrt post_incdec.

Actually, we may be ok here, but only by accident.  The plan we've
discussed is to do "small" if-conversion during early jump, as we
do now.  Small is probably limited to one or two instructions.

More aggressive if-conversion -- particularly for ports with lots
of predicate registers -- will happen after flow2.  The reason is
to let register allocation see the control-flow structure.

Since auto_incdec is generated during flow1, and there are no jump
passes between there and reload, we won't see something of the
form you describe above until the post-reload if-converters go to
work.  I can't think of any other reloading that would be unsafe
to do unconditionally.

> Hmm, how would the @pred work?

That's some stuff I'm currently working on in genrecog and genattrtab. 

The idea is that @foo magically generates a predicate for genrecog to
use that is true iff get_attr_foo is true.  This makes it easy to 
mark which instructions are or are not predicable.

> Or would there be some other way of describing whether an insn can
> be safely predicated?

You can use any method you can code up into a boolean function.
Using attributes is almost certainly going to be easier though.

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

No.



r~

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