On Monday, 23/7/2018 16:22:24 EEST Jeff Law wrote: > On 07/19/2018 08:12 PM, Dimitar Dimitrov wrote: > > 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")]) > > So my only worry with that is dataflow -- ie, how many registers have > their values changed isn't expressed in the pattern in a way that the > generic parts of the compiler understand. That's likely to cause some > problems. My intention was to simplify the machine description, but apparently I went too far. I'll instead use the s390x port that Jakub recommended as a starting point. It seems to fit the PRU requirements.
Thanks, Dimitar
