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.
Kyrill
Thanks,
Kyrill
Thanks,
Nikolai
