-(define_split +; Split the load of 64-bit constant into two loads for high and low 32-bit parts respectively +; to see if we can load them in fewer instructions or fewer cycles. +; For the small 64-bit integer constants that satisfy constraint J, the instruction pattern +; thumb1_movdi_insn has a better way to handle them. >+(define_split >+ [(set (match_operand:ANY64 0 "arm_general_register_operand" "") >+ (match_operand:ANY64 1 "const_double_operand" ""))] >+ "TARGET_THUMB1 && reload_completed && !satisfies_constraint_J (operands[1])" >+ [(set (match_dup 0) (match_dup 1)) >+ (set (match_dup 2) (match_dup 3))]
Not ok - this splitter used to kick in in ARM state, now you've turned it off. Look at the movdi patterns in ARM state which deal with it immediate moves with a #. So, the condition should read (TARGET_32BIT) || ( TARGET_THUMB1 && ....) Ok with that change and if no regressions. regards Ramana On Fri, Apr 11, 2014 at 8:36 AM, Terry Guo <terry....@arm.com> wrote: > Hi there, > > Current gcc prefers to using two LDR instructions to load 64bit constants. > This could miss some chances that 64bit load can be done in fewer > instructions or fewer cycles. For example, below code to load 0x100000001 > > mov r0, #1 > mov r1, #1 > > is better than current solution: > > ldr r1, .L2+4 > ldr r0, .L2 > .L2: > .word 1 > .word 1 > > The attached patch intends to split 64bit load to take advantage of such > chances. Tested with gcc regression test on cortex-m0. No new regressions. > > Is it ok to stage 1? > > BR, > Terry > > gcc/ > 2014-04-11 Terry Guo <terry....@arm.com> > > * config/arm/arm.md (split 64-bit constant for Thumb1): New split > pattern. > > gcc/testsuite/ > 2014-04-11 Terry Guo <terry....@arm.com> > > * gcc.target/arm/thumb1-load-64bit-constant-1.c: New test. > * gcc.target/arm/thumb1-load-64bit-constant-2.c: Ditto. > * gcc.target/arm/thumb1-load-64bit-constant-3.c: Ditto.
