Browse Prior Art Database

Source Level Debugging of Code After If-Conversion

IP.com Disclosure Number: IPCOM000123781D
Original Publication Date: 1999-Apr-01
Included in the Prior Art Database: 2005-Apr-05
Document File: 3 page(s) / 138K

Publishing Venue

IBM

Related People

Gschwind, MK: AUTHOR

Abstract

To take advantage of the available issue bandwidth, statically scheduled instruction set architectures such as EPIC or VLIW must aggressively re-arrange code to exploit available issue bandwidth. If-conversion offers the prospect of removing small control flow splits and joins (such as "diamonds" and "hammocks") by the use of predicated execution. Applying if-conversion to code allows to eliminate problems associated with frequent branching such as reducing the size of the scheduling window and branch penalties for branch misprediction.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 46% of the total text.

Source Level Debugging of Code After If-Conversion

   To take advantage of the available issue bandwidth,
statically scheduled instruction set architectures such as EPIC or
VLIW must aggressively re-arrange code to exploit available issue
bandwidth.  If-conversion offers the prospect of removing small
control flow splits and joins (such as "diamonds" and "hammocks") by
the use of predicated execution.  Applying if-conversion to code
allows to eliminate problems associated with frequent branching such
as reducing the size of the scheduling window and branch penalties
for branch misprediction.

   While if-conversion and predicated execution offer the
ability to eliminate such control flow operations and increase
performance in statically scheduled code, it has an adverse impact
on the ability to perform source level debugging.  Typically, source
level debugging is achieved by correlating instruction addresses to
particular source code lines.  Thus, when a program is interrupted,
the original source line can be reported to the user by inspecting
the program counter and looking up the associated program line.

   This approach to determine source line information from
the program counter value has worked quite well until now since the
the control flow of the object code program largely mirrored the
control flow of the source level program.(1)  Consider the following
example:
  1 if (x >= 0)
  2 a = (x+y)/2;
  3 else
  4 a = 0;
  (1) This method has some unexpected effects, especially in
      optimized code, where source level control flow may seem
      to be "diverted" for some time to account for instruction
      movement through a variety of optimizations.  This behavior
      has become tolerated by users who use high optimization
      levels for their code.

   A compiler might translate this source level statements to
the following instructions and annotate the object file with line
information:
  0x1000 cmpwi cr0 = rx, 0                ; line 1
  0x1004 bc true, cr0.lt, L1              ; line 1
  0x1008 add r0 = rx, ry                  ; line 2
  0x100C srwi ra = r0, 1                  ; line 2
  0x1010 b L2                             ; line 2
  0x1014 L1:
  0x1018 li ra = 0                        ; line 4
  0x101C L2:

   Using the instruction address as indicator of program
source code location associated with an instruction is not
sufficient in the case of if-converted code, since the control flow
of the source program may contain diamonds or hammocks which may have
been predicated and the control flow removed.  Thus, in any given
long instruction word, it is impossible to establish which path is
actually executed, since the path of the control flow in the source
program (diamond) no longer corresponds to the control flow in the
object program (straightline predicated co...