This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 11/11] Increase MAX_MAX_OPERANDS limit


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]