Re: [PATCH 11/11] Increase MAX_MAX_OPERANDS limit

[Dimitar Dimitrov <dimitar at dinux dot eu>]

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

Attachment: pru-ldst-multiple.md.gz
Description: application/gzip