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] |
Richard Henderson wrote:other
> > While looking at PR 11693, I noticed a bunch of schedules like
> > .mlx
> nop 0
> movl r18 = -4611686018427387904
> .mmb
> nop 0
> addl r19 = 1632, r0
> nop 0
> > One immediately notices that this could have been
> > .mlx
> addl r19 = 1632, r0
> movl r18 = -4611686018427387904
> > and used half the code space.
> > The issue, as far as I've been able to tell, is that *both* sequences
> can be executed in one cycle, and that the scheduler is given no
> metric by which to gauge the relative merits of these two sequences.
> > Have you any thoughts on what could be done here?
It can not be a pitfall of bundling because bundling never changes the insn order. So it is a pitfall of insn scheduler. The most probably movl has a bigger priority. In this case we could add another hook (or well one more scheduler hook) to recognize such situation during the first cycle multipass insn scheduler. There is a small probability that the first cycle multipass insn scheduler returns insns not in the original order when it could do this (I need to check). Fixing the last possible problem still does not remove the 1st problem. So I think there is no other way to fix it without introducing a new scheduler hook.
I'll try to make a patch to fix the problem on this week.
VladI am intrested in this problem.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |