This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Problems with conditional execution and thumb code generation
- To: rth at cygnus dot com, gcc-bugs at gcc dot gnu dot org
- Subject: Problems with conditional execution and thumb code generation
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Fri, 18 Aug 2000 16:43:45 +0100
- cc: rearnsha at arm dot com
- Organization: ARM Ltd.
- Reply-To: rearnsha at arm dot com
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).
Suggestions?
R.