This is the mail archive of the
mailing list for the GCC project.
Re: DFA Scheduler - unable to pipeline loads
- From: Adam Nemet <anemet at caviumnetworks dot com>
- To: "Matt Lee" <reachmatt dot lee at gmail dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 4 Sep 2007 18:57:15 -0700
- Subject: Re: DFA Scheduler - unable to pipeline loads
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com>
Matt Lee writes:
> In any case, I am trying to optimize the case where there is clearly no
> aliasing. Your suggestion regarding movmemsi is interesting. I have not used
> this pattern before and assumed that it was required only when something
> special must be done to do block moves. In my architecture, a block move is
> not special and is equivalent a series of loads and stores. Why do I need
> this pattern and why/how does the aliasing conflict become a non-issue when
> defining this pattern?
When expanding this pattern you can take advantage of the fact that source and
destination cannot overlap. Thus, you can expand the loads and stores more
freely (see mips_block_move_straight). The type-based aliasing code does not
retain this information so as soon as you are finished expanding RTL you have
practically frozen the order of these instructions.
I agree with you that you should not be required to provide this pattern but I
don't think there is better way currently. We would need to subset the
original alias set similarly to restrict but since memcpy switches the alias
set of its operands to zero this approach would not work.