Re: Problems with conditional execution and thumb code generation

[Michael Meissner <meissner at cygnus dot com>]

On Fri, Aug 18, 2000 at 05:21:00PM +0100, Richard Earnshaw wrote:
> 
> meissner@cygnus.com said:
> > The sad thing is that none of the cond-exec code is going to be of any
> > use 
> > when I'm generating thumb code, but there is currently no way to
> > disable 
> > this processing.  Maybe if there is no ready solution to the above, we
> > 
> > could turn the #ifdefs into something that is dynamic (like we do for 
> > endianness).
> 
> > It is already dynamic, by the insn recognizers failing if machine ==
> > thumb.
> 
> Yes, none of the patterns will match, but this misses the point I was 
> trying to make.  In flow.c we currently have
> 
> 	...
> #ifdef HAVE_conditional_execution
> 	...
> #endif
> 	...
> 
> I was suggesting that we might convert this to 
> 
> 	...
> #ifdef HAVE_conditional_execution
> 	if (HAVE_conditional_execution)
> 	  {
> 	    ...
> 	  }
> #endif
> 	...

As Richard says, you don't have a single insn to test the condition on.  My
original code had switches -fconditional-execution and -fconditional-execution2
that were tested before doing the conditional execution expansion before reload
and after reload (and presumably in OVERRIDE_OPTIONS and OPTIMIZE_OPTIONS you
could reset it for thumb mode).  When rth reorganized the code, he droped the
switches.

> And then on the ARM make HAVE_conditional_execution dependent of the 
> -mthumb flag not being set (for most other targets it would be a constant).
> 
> > In addition, look at IFCVT_MODIFY_TESTS, IFCVT_MODIFY_INSN,
> > IFCVT_MODIFY_FINAL, and IFCVT_MODIFY_CANCEL.  The port I'm currently
> > working on has normal condition code registers set by the compare
> > instructions and used by the branches, and then a separate set of
> > registers for doing conditional execution that is set from the
> > condition code registers and a second compare instruction. If I'm not
> > able to find a free register for conditional execution,
> > IFCVT_MODIFY_TESTS sets the two tests to NULL_RTX, and it stops the
> > processing (otherwise it modifies the tests to use the conditional
> > execution register, and IFCVT_MODIFY_FINAL then inserts the second
> > compare instruction).
> 
> So you are suggesting I might be able to have
> 
> #define IFCVT_MODIFY_INSN(PAT, INSN) PAT = TARGET_THUMB ? NULL_RTX : PAT
> 
> But how would that prevent the abort in flow that I have at the moment, 
> IFCVT_MODIFY_INSN is used in ifcvt.c, which isn't run until after flow has 
> built the conditional register use data structures.

No, it wouldn't change your current abort if it is done before it gets to the
ifcvt code.

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482