Problems with conditional execution and thumb code generation

Michael Meissner meissner@cygnus.com
Fri Aug 18 09:04:00 GMT 2000


On Fri, Aug 18, 2000 at 04:43:45PM +0100, Richard Earnshaw wrote:
> 
> Richard,
> 
> In flow.c:init_propagate_block_info we have
> 
> 
>     /* Compute which register lead different lives in the successors.  */
>     if (bitmap_operation (diff, bb_true->global_live_at_start,
>                           bb_false->global_live_at_start, BITMAP_XOR))
>       {
>         if (GET_CODE (XEXP (cond_true, 0)) != REG)
>           abort ();
>         SET_REGNO_REG_SET (pbi->reg_cond_reg, REGNO (XEXP (cond_true, 0)));
> 
>         /* For each such register, mark it conditionally dead.  */
>         EXECUTE_IF_SET_IN_REG_SET
> 	....
> 
> But when generating thumb code (arm-elf configuration, building multilibs 
> with -mthumb) I have the following insn for a jump:
> 
> (jump_insn 46 44 76 (set (pc)
>         (if_then_else (eq (subreg:SI (reg/v:DI 34) 0)
>                 (const_int 0 [0x0]))
>             (label_ref 60)
>             (pc))) 203 {cbranchsi4} (nil)
>     (nil))
> 
> which is then picked apart by the above code to give us the condition
> 
> 	(eq (subreg:SI (reg/v:DI 34) 0)
>                 (const_int 0 [0x0]))
> 
> which of course then triggers an assertion failure because we have a 
> subreg not a reg.
> 
> Doesn't the above code need to handle subregs?  If not, is there a 
> straight-forward way to prevent them appearing at this point?
> 
> 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.

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

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


More information about the Gcc-bugs mailing list