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