On петък, 22 юни 2018 г. 19:41:55 EEST Jakub Jelinek wrote: > On Fri, Jun 22, 2018 at 11:33:06AM -0600, Jeff Law wrote: > > On 06/13/2018 12:58 PM, Dimitar Dimitrov wrote: > > > The PRU load/store instructions can access memory with byte > > > > > > granularity for all 30 of its 32-bit GP registers. Examples: > > > # Load 17 bytes from address r0[0] into registers r10.b1-r14.b2 > > > lbbo r10.b1, r0, 0, 17 > > > > > > # Load 100 bytes from address r28[0] into registers r0-r25 > > > lbbo r0.b0, r28, 0, 100 > > > > > > The load/store multiple patterns declare all subsequent registers > > > as distinct operands. Hence the need to increase the limit. > > Can't you have a look on how other targets, e.g. arm, aarch64, s390x > etc. handle load/store multiple patterns, e.g. with match_parallel or > match_par_dup? > The instructions then don't have dozens of operands, and the predicate > is just supposed to check everything is the way it should be. 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. I make no distintion for class - patterns accept any GP register. Regards, Dimitar
pru-ldst-multiple.md.gz
Description: application/gzip
