On 09/11/15 08:14, Nikolai Bozhenov wrote:
On 11/06/2015 08:16 PM, Kyrill Tkachov wrote:
On 06/11/15 17:09, Kyrill Tkachov wrote:
On 06/11/15 17:07, Nikolai Bozhenov wrote:
On 11/06/2015 04:46 PM, Ramana Radhakrishnan wrote:
Hi!
I faced the same issue but I had somewhat different RTL for the consumer:
(insn 20 15 21 2 (set (reg/i:SI 0 r0)
(minus:SI (subreg:SI (reg:DI 117) 4)
(mult:SI (reg:SI 123)
(reg:SI 114)))) gasman.c:4 48 {*mulsi3subsi})
where (reg:DI 117) is produced by umulsidi3_v6 instruction. Is it
really true that (subreg:SI (reg:DI 117) 4) may be forwarded in one
cycle in this case?
If the accumulator can be forwarded (i.e. a SImode register), there isn't a
reason why a subreg:SI (reg:DI) will not get forwarded.
The subreg:SI is an artifact before register allocation, thus it's a
representation issue that the patch is fixing here unless I misunderstand your
question.
I mean, in my example it is not the multiplication result that is
forwarded but its upper part. So, shouldn't we check that offset in a
subreg expression is zero? Or is it ok to forward only the upper part
of a multiplication?
Could you please post the full RTL instruction we're talking about here as it
appears in the scheduler dump?
So that we're all on the same page about which case we're talking about.
Sorry, missed the above instruction.
This subreg is just a pre-register allocation representation of the instruction
and will go away after reload.
This particular function only really has a real effect in post-reload
scheduling as it's only there when the final
register numbers are known.
I see. aarch_accumulator_forwarding always returns 0 for virtual
registers. But isn't it overly pessimistic to assume that accumulator
forwarding is never possible at sched1? I wonder if it would be better
to be more optimistic about register allocation outcome. I mean, in
case of virtual registers we could assume forwarding from A to B if B
is the only consumer of A's result. Something like this:
if (REGNO (dest) >= FIRST_VIRTUAL_REGISTER
|| REGNO (accumulator) >= FIRST_VIRTUAL_REGISTER)
return (DF_REG_USE_COUNT (REGNO (dest)) == 1)
&& (DF_REF_INSN (DF_REG_USE_CHAIN (REGNO (dest))) == consumer);
else
return REGNO (dest) == REGNO (accumulator);
Interesting...
As far as I know sched1 tries to minimise live ranges before register
allocation rather than trying to
perform the most exact pipeline modelling, since we only know the exact
registers used in sched2.
What you're proposing is a heuristic, so it would need benchmarking results and
analysis to be considered.
Thanks,
Kyrill
Thanks,
Nikolai
