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

Reply via email to