This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: DFA Scheduler - unable to pipeline loads


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.

Adam


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]