On събота, 23 юни 2018 г. 20:35:23 EEST Jakub Jelinek wrote: > On Sat, Jun 23, 2018 at 03:26:50PM +0300, Dimitar Dimitrov wrote: > > I took arm/ldmstm.md as an inspiration. See attached machine description > > for PRU that requires the increase. I omitted this machine-generated MD > > file from my first patch set, but per comments will include it in v2. > > > > PRU has a total of 32 32-bit registers with flexible subregister > > addressing. The PRU GCC port represents the register file as 128 > > individual 8-bit registers. Rationale: > > http://gcc.gnu.org/ml/gcc/2017-01/msg00217.html > > > > Load/store instructions can load anywhere between 1 and 124 consecutive > > 8-bit registers. The load/store-multiple patterns seem to require > > const_int_operand offsets for each loaded register, hence the explosion > > of operands. > If it is consecutive only, then you could represent those that load a lot of > registers using wider modes, so represent e.g. that 124 register load as 15 > DImode loads + 1 SImode. > > Jakub Jeff, Jakub, thank you for raising a concern that increasing MAX_MAX_OPERANDS is suspicous.
I think a better approach is to altogether avoid expansion, and instead declare define_insn. Advantages are that: - machine description is greatly simplified; - there is no machine-generated code; - I don't need to increase MAX_MAX_OPERANDS. I'll revise the PRU port and send patch v2. Here is how I intend to implement the pattern: (define_insn "load_multiple" [(unspec_volatile [(parallel [(match_operand:QI 0 "register_operand" "=r") (match_operand:BLK 1 "memory_operand" "m") (match_operand:VOID 2 "const_int_operand" "i")])] UNSPECV_LOAD_MULTPLE)] "" "lb%B1o\\t%b0, %1, %2" [(set_attr "type" "ld") (set_attr "length" "4")]) Regards, Dimitar