This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 11/11] Increase MAX_MAX_OPERANDS limit
- From: Jeff Law <law at redhat dot com>
- To: Dimitar Dimitrov <dimitar at dinux dot eu>, Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 23 Jul 2018 16:22:24 -0600
- Subject: Re: [PATCH 11/11] Increase MAX_MAX_OPERANDS limit
- References: <firstname.lastname@example.org> <6053874.PKi0MiDhFJ@tpdeb> <20180623183523.GZ7166@tucnak> <5052848.UfHbQnDTgZ@tpdeb>
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:
>>> 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.
> 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"
> [(parallel [(match_operand:QI 0 "register_operand" "=r")
> (match_operand:BLK 1 "memory_operand" "m")
> (match_operand:VOID 2 "const_int_operand" "i")])]
> "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