This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [0/4] Modulo scheduling with haifa-sched for C6X
- From: Bernd Schmidt <bernds_cb1 at t-online dot de>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>, richard dot sandiford at linaro dot org
- Date: Mon, 03 Oct 2011 15:59:04 +0200
- Subject: Re: [0/4] Modulo scheduling with haifa-sched for C6X
- References: <4E6FCFE3.5010807@codesourcery.com> <g4vcsvijhj.fsf@richards-thinkpad.stglab.manchester.uk.ibm.com> <4E707B58.1070705@codesourcery.com> <g44nzqlc08.fsf@richards-thinkpad.stglab.manchester.uk.ibm.com>
On 10/03/11 10:23, Richard Sandiford wrote:
> Bernd Schmidt <bernds@codesourcery.com> writes:
>> On 09/14/11 11:03, Richard Sandiford wrote:
>>> ...I didn't see from an admittedly quick read of the patch how you
>>> handle memory disambiguation between iterations. If a loop includes:
>>>
>>> lb $3,($4)
>>> sb $5,1($4)
>>>
>>> then the two instructions can be reordered by normal ebb scheduling,
>>> but the inter-iteration conflict is important for modulo scheduling.
>>
>> There's nothing special to handle, I think. sched-deps should see that
>> the ld in iteration 1 is DEP_ANTI against the sb in iteration 0
>> (assuming there's also an increment).
>
> For the record, I don't agree that we should rely on register
> dependencies to handle memory dependencies. It's possible for MEMs in
> different iterations to alias without there being a register dependence
> between them.
I don't know what you mean by "register dependence" here. sched-deps
analyzes MEMs for whether they depend on each other, but the term
"register dependence" suggests you aren't thinking about this.
If there was a problem, then rtl loop unrolling would also cause it
(since the modulo scheduling patch effectively does nothing else). Are
you sure there really is a problem?
Bernd