Re: RFC: Explicit move preference hints
Vladimir Makarov wrote: > > As I correctly understand, you just want an intuitive allocation. The > current allocation performance has the same quality as the intuitive one. Performance is affected as well but I didn't want to go into details as that distracts from the underlying issue. But if you're interested - on AArch64 there is an optimization phase dedicated to renaming registers to fix various issues with FMAC. It doesn't work as well as expected since it is hard to do a global rename after register allocation. Given the register allocator already supports move preferencing, using that is far simpler. A few experiments showed that move preferencing does much better. > In this case it would be hard for me to approve such change because it > gives no performance improvement but complicates machine description > definition which is already too complicated. I'm not suggesting to add extra complication, just to make existing syntax work as expected. My experiment required 2 lines of code. > I think if it is important for some cases may be it is possible to find > an alternative solution without introducing a new hint. Segher proposed > some solutions. They might work. If they don't work we could try to > change heuristics in LRA, for example, to favor copy destination with > the first operand to improve some regularity for human eyes. Unfortunately there is no alternative today. The allocator always prefers copies to the first dead operand - there is nothing you can do about it (reordering operands isn't possible in most patterns). Wilco
Re: RFC: Explicit move preference hints
Segher Boessenkool wrote: > > "0,r" might work, or "0,?r", or similar (alternatives have commas > between them). No, it doesn't work at all. But that is no surprise if you look at ira_get_dup_out_num. It iterates over the constraint string and if you have anything that matches after a "0", the "0" constraint is simply ignored. So "0" works only if it is the only constraint, and any combination with an unconstrained register makes no difference irrespectively whether it is "0r" or "0, r" or "0, ?!^$r". So that is why I'd like to fix this so it actually works like you'd expect. Wilco
Re: RFC: Explicit move preference hints
On 8/23/17 5:22 PM, Segher Boessenkool wrote:
> On Wed, Aug 23, 2017 at 05:15:03PM +, Wilco Dijkstra wrote:
>> What is a preferred alternative? The current register allocator simply
>> ignores
>> any combination of "0r", "r0", ("r", "0") and ("0", "r") and just picks the
>> most
>> generic alternative. So we need a new way to specify a move preference
>> which won't constrain the allocation ("0" would always force the preference
>> but
>> will also insert redundant moves which then cannot be removed later).
>
> "0,r" might work, or "0,?r", or similar (alternatives have commas
> between them).
Right and alternatives that come first in the string are preferred
over alternatives that come later in the string, so in Segher's
example above, if both '0' and 'r' (or '?r') constraints are "ok",
then '0' is preferred over 'r' (or '?r').
Peter
Re: RFC: Explicit move preference hints
On 08/22/2017 06:48 AM, Wilco Dijkstra wrote: Hi, The register allocator inserts move preferences when an instruction has one or more dead sources in add_insn_allocno_copies. If an instruction doesn't have a matching constraint (eg. "0"), then any dead source is treated as a copy with all destination registers with a low priority. In reality what appears to happen is that the first dead source is treated as a copy. This leads to non-intuitive allocations in eg. 4-register FMAs. Here you'd prefer to have the accumulator and destination to use the same register when possible: so fmadd d2, d0, d5, d2 instead of fmadd d0, d0, d5, d2. Would it be reasonable to add an explicit move preference feature? For example use "r#0" to indicate in ira_get_dup_out_num that an operand prefers to be the same as the destination if possible. This would use a lower move priority than "0" to avoid constraining the allocation but a bit higher than a simple dead source (eg. freq / 4 or freq / 2). Wilco, sorry for a delay with the answer. I needed some time to think about it. Thank you for writing about the problem. As I correctly understand, you just want an intuitive allocation. The current allocation performance has the same quality as the intuitive one. In this case it would be hard for me to approve such change because it gives no performance improvement but complicates machine description definition which is already too complicated. I think if it is important for some cases may be it is possible to find an alternative solution without introducing a new hint. Segher proposed some solutions. They might work. If they don't work we could try to change heuristics in LRA, for example, to favor copy destination with the first operand to improve some regularity for human eyes.
Re: RFC: Explicit move preference hints
On Wed, Aug 23, 2017 at 05:15:03PM +, Wilco Dijkstra wrote:
> Segher Boessenkool wrote:
> > On Tue, Aug 22, 2017 at 10:48:17AM +, Wilco Dijkstra wrote:
> > > The register allocator inserts move preferences when an instruction has
> > > one or more dead sources in add_insn_allocno_copies. If an instruction
> > > doesn't have a matching constraint (eg. "0"), then any dead source is
> > > treated
> > > as a copy with all destination registers with a low priority. In reality
> > > what
> > > appears to happen is that the first dead source is treated as a copy. This
> > > leads to non-intuitive allocations in eg. 4-register FMAs. Here you'd
> > > prefer to have the accumulator and destination to use the same register
> > > when possible: so fmadd d2, d0, d5, d2 instead of fmadd d0, d0, d5, d2.
> >
> > You could add a preferred alternative that uses "0" to such instruction
> > patterns, will that help?
>
> What is a preferred alternative? The current register allocator simply ignores
> any combination of "0r", "r0", ("r", "0") and ("0", "r") and just picks the
> most
> generic alternative. So we need a new way to specify a move preference
> which won't constrain the allocation ("0" would always force the preference
> but
> will also insert redundant moves which then cannot be removed later).
"0,r" might work, or "0,?r", or similar (alternatives have commas
between them).
Segher
Re: RFC: Explicit move preference hints
Segher Boessenkool wrote:
> On Tue, Aug 22, 2017 at 10:48:17AM +, Wilco Dijkstra wrote:
> > The register allocator inserts move preferences when an instruction has
> > one or more dead sources in add_insn_allocno_copies. If an instruction
> > doesn't have a matching constraint (eg. "0"), then any dead source is
> > treated
> > as a copy with all destination registers with a low priority. In reality
> > what
> > appears to happen is that the first dead source is treated as a copy. This
> > leads to non-intuitive allocations in eg. 4-register FMAs. Here you'd
> > prefer to have the accumulator and destination to use the same register
> > when possible: so fmadd d2, d0, d5, d2 instead of fmadd d0, d0, d5, d2.
>
> You could add a preferred alternative that uses "0" to such instruction
> patterns, will that help?
What is a preferred alternative? The current register allocator simply ignores
any combination of "0r", "r0", ("r", "0") and ("0", "r") and just picks the most
generic alternative. So we need a new way to specify a move preference
which won't constrain the allocation ("0" would always force the preference but
will also insert redundant moves which then cannot be removed later).
Wilco
Re: RFC: Explicit move preference hints
Hi! On Tue, Aug 22, 2017 at 10:48:17AM +, Wilco Dijkstra wrote: > The register allocator inserts move preferences when an instruction has > one or more dead sources in add_insn_allocno_copies. If an instruction > doesn't have a matching constraint (eg. "0"), then any dead source is treated > as a copy with all destination registers with a low priority. In reality what > appears to happen is that the first dead source is treated as a copy. This > leads to non-intuitive allocations in eg. 4-register FMAs. Here you'd > prefer to have the accumulator and destination to use the same register > when possible: so fmadd d2, d0, d5, d2 instead of fmadd d0, d0, d5, d2. You could add a preferred alternative that uses "0" to such instruction patterns, will that help? Segher
RFC: Explicit move preference hints
Hi, The register allocator inserts move preferences when an instruction has one or more dead sources in add_insn_allocno_copies. If an instruction doesn't have a matching constraint (eg. "0"), then any dead source is treated as a copy with all destination registers with a low priority. In reality what appears to happen is that the first dead source is treated as a copy. This leads to non-intuitive allocations in eg. 4-register FMAs. Here you'd prefer to have the accumulator and destination to use the same register when possible: so fmadd d2, d0, d5, d2 instead of fmadd d0, d0, d5, d2. Would it be reasonable to add an explicit move preference feature? For example use "r#0" to indicate in ira_get_dup_out_num that an operand prefers to be the same as the destination if possible. This would use a lower move priority than "0" to avoid constraining the allocation but a bit higher than a simple dead source (eg. freq / 4 or freq / 2). Wilco
