This is the mail archive of the gcc-patches@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: Fix two testsuite failures on k6-pc-linux-gnu


 In message <00e001c21e01$fe2603e0$0b4f24d5@zephyr>, "Eric Botcazou" writes:
 >However, the two failures have nothing to do with the 'dbra' transformation
 >of the loop optimizer: they are triggered by the mishandling of short
 >branches on i386. Namely, gcc produces a short branch instruction ('loop')
 >to a label which is out of the range of the instruction.
Right.

 > This patch conditionally sets the type of the 'loop' instruction, which
 > doesn't work (presumably order of evaluation issues). Simply reverting
 > to the old code for this instruction fixes the two failures.
Nope.  It has nothing to do with order of evaluation issues.  The
underlying issue is that the compiler isn't aware that the length of
this instruction varies and that the varying length effects how we will
output the instruction.

So if we look at how final works we see that it will try to compute
the difference between the address of the loop instruction and its 
target.  In the case where we've seen the target, we have a known
address and we can get a reasonable length computation.

However, if we are working with a target we have not seen (ie, the
target appears *after* the loop instruction), then we use the value
zero for the target address.

The first loop instruction appears at offset 0xae in the output file.  So
we compute the difference as -0xae which appears to be within the range of
a loop instruction.

Later compute the address of the target as being something like 0x147, but
since we do not know that the loop instruction has a varying length we do
not re-compute its length.

This leads to incorrect output when we output assembly code for the
instruction.


I recommend separating out the other bugfixes as a separate patch -- those
should be OK as-is.

For the problem with the loop instruction, I'm not entirely sure how it
should best be fixed.  One way would be your approach.  Another would
be to fix genattrtab to mark the loop insn as having a varying length,
another would be to twiddle the md file so that genattrtab recognizes
it as having a variable length.  Thoughts folks?

[ I also question the value in having type information for this insn since
  there's little freedom for handling multi and ibr type instructions. ]

jeff


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