DPCL now (version 3.4.2 and later) supports placing instrumentation at the block level as well as the existing support for placing instrumentation at the function level. Due to limitations in the data provided by the compiler for identifying blocks, block level instrumentation is only supported for unoptimized code. With optimized code, the compiler may so radically rewrite the object code that the identity of blocks at the source code level has been lost. Placing instrumentation at the block level in optimized code is still possible, but the placement of the block level instrumentation may not be what was expected from examining the source code structure.
Compiling an OpenMP application implies that the compiler applies optimizations to the generated code. These optimizations may rewrite the object code such that the identity of blocks at the source code level is lost, affecting placement of block level instrumentation in the same manner as non-OpenMP code which is compiled with optimizer options enabled.
Any source file which is to be instrumented at the block level needs to be compiled with the –g and –qdpcl flags. FORTRAN source code must be compiled with both the –g and –qdpcl flags. C and C++ code which is compiled with only the –g flag will have only blocks which have local variables declared at their scoping level visible. In order for all blocks within a C or C++ source file to be visible, the file must be compiled with both the –g and –qdpcl flags.
Although no new methods have been added with the addition of source block support, source block objects and their associated instrumentation points, the sourceObj tree has changed. It now contains more objects. There are SOT_block objects below the function level. Some instrumentation points have been added, and some have been moved.
The inst points that have been added are the block entry and block exit points.
Previously all of the call sites in the function were in the inclusive point and exclusive point array, because the function was as deep as the source tree went. The inclusive point list will still contain all of the call sites. To get all points using the exclusive_point calls, it will now be necessary to call exclusive_point from the appropriate block objects. This can be achieved by navigating down through the source tree.
The source structure of the application is represented in DPCL by a tree containing SourceObj objects. Each object has a type (SourceType) which can be determined by a call to SourceObj::src_type(). The possible types are:
Depending on the type of the source object, different methods will be used to query its attributes or relationship to other source objects. For example, the child() and child_count methods are useful in many cases, but the get_variable_name() method is very specific.
At the top of the tree is the program object which is obtained by a call to Proccess::get_program_object(). The program object has children of type SOT_module which represent the source files. To get to the children of a source object, first find out how many there are using child_count(). After that, the individual child objects can be obtained using child(i) where i is within the range returned from child_count().
The source file (or module level) is the default level of source tree representation chosen by DPCL. From the module level down, the tool developer can choose which of the source files (modules) to gather detailed information about. Only the chosen (expanded) files will actually be represented in detail in the DPCL library client code. The method SourceObj::expand() is used at the module level to cause more detail to be sent back to the client. Prior to the expand call, the tree is only available at the module level.
Instrumentation points are not available at any level until a module has been expanded. After the module has been expanded the exclusive_point_count(), exclusive_point(i), inclusive_point_count() and inclusive_point(i) calls can be made with successful results on many of the SourceObj objects in the expanded tree. The inclusive point calls will yield all points associated with the current object and its descendants. The exclusive point calls will only yield points associated with the current object. Since a file is not thought to have points not associated with its descendants, there are no exclusive points associated with the module.
After the expand, the expanded module will then have children where some of these children (type SOT_data) represent the global data items, and some of the objects (type SOT_function) represent the functions. Children at this level and other levels are found by using the child_count() and child(i) methods.
Children of the function are function parameters (type SOT_data) or a source block (type SOT_block). This source block direct child of a function is a placeholder for local variable scope in the function. Any source block may have more children of type SOT_block.
DPCL tools that wish to take advantage of the additional source code representation that is now available will not have to use any new methods. The existing child_count() and child(i) will have to be used below the function level and it will be necessary to check for the SOT_block type.
Although the calls to get the points are the same as they were previously, the results are somewhat different because the source tree is more granular than before. There will also be more instrumentation points in number when begin and end source block points are found. So, the tool developer can still request all the points (inclusively) at the function or module level as before, but the returned list will be larger if begin and end block points are found. In addition, the flexibility now exists to get smaller lists of points down to the source block level by getting the points exclusively at the SOT_block SourceObj's.