https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712
sudi at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |law at redhat dot com,
| |vmakarov at redhat dot com
--- Comment #4 from sudi at gcc dot gnu.org ---
What I have observed so far is that the failure occurs based on how the
scheduler (sched1) chooses to schedule the movmem12b instructions (insn 16 in
all the cases below). If that
instruction is scheduled a bit later (even by one instruction), its all good!
Even though the movmem12b instruction has a very heavy demand on the registers,
shouldn't the allocator and/or the scheduler be able to detect that? Is this a
scheduler problem or an allocator problem or neither?
Example Passing cases:
-mfloat-abi=softfp -mthumb -march=armv6 m-bug.c -O2 -S -fdump-rtl-sched1
;; Pressure summary: GENERAL_REGS:8
;; 0--> b 0: i 13 r119=[`*.LC1']
:(l_a+e_1),l_dc1,l_dc2,l_wb:GENERAL_REGS+1(1)
;; 1--> b 0: i 12 r118=sfp-0x10
:e_1,e_2,e_3,e_wb:@GENERAL_REGS+1(1)
;; 2--> b 0: i 2 r111=r0
:e_1,e_2,e_3,e_wb:@GENERAL_REGS+1(0):model 0
;; 3--> b 0: i 16
{[r118]=[r119];[r118+0x4]=[r119+0x4];[r118+0x8]=[r119+0x8];r120=r118+0xc;r121=r119+0xc;clobber
scratch;clobber scratch;clobber
scratch;}:(l_a+e_1),l_dc1*2,l_dc2,l_wb:GENERAL_REGS+2(1)
...
,..
Example Failing case:
-mfloat-abi=softfp -mthumb -march=armv6 m-bug.c -O2 -S -fdump-rtl-sched1
-mtune=cortex-m0plus
;; Pressure summary: GENERAL_REGS:8
;; 0--> b 0: i 13 r119=[`*.LC1']
:core:GENERAL_REGS+1(1)
;; 1--> b 0: i 12 r118=sfp-0x10
:core:@GENERAL_REGS+1(1)
;; 2--> b 0: i 16
{[r118]=[r119];[r118+0x4]=[r119+0x4];[r118+0x8]=[r119+0x8];r120=r118+0xc;r121=r119+0xc;clobber
scratch;clobber scratch;clobber scratch;}:core*4:GENERAL_REGS+2(1)
...
...
Other passing option:
mfloat-abi=softfp -mthumb -march=armv6 m-bug.c -O2 -S -fdump-rtl-sched1
-mtune=cortex-m7
Other failing option:
-mfloat-abi=softfp -mthumb -march=armv6 m-bug.c -O2 -S -fdump-rtl-sched1
-mtune=cortex-m4
