Byfl v1.5 for LLVM/Clang/DragonEgg v3.5.2

This is mostly a clean-up release of Byfl. The main user-visible change is that instrumented programs now produce far less textual output: only the BYFL_INFO and BYFL_SUMMARY lines. The intention is to reduce clutter. Most of the now-removed textual output was too wide to fit in any normal-sized window without wrapping. No changes have been made to the binary data an instrumented program writes to the .byfl file.

At configuration time, convenient new EXTRA_CPPFLAGS, EXTRA_CFLAGS, EXTRA_CXXFLAGS, and EXTRA_LDFLAGS variables enable users to append flags to those needed by the LLVM SDK.

The build-llvm-byfl script has been removed. It was too difficult to maintain, especially relative to its limited utility.

Byfl v1.4 for LLVM/Clang v3.7.0

Byfl has improved a lot since version 1.3. Here are some of the highlights from the long list of changes:

• -bf-data-structs logs data-structure lifetimes.
• Applications can invoke bf_enable_counting() explicitly to dynamically enable and disable most Byfl run-time functionality. This can be used, for example, to instrument only a single iteration of a critical loop.
• Byfl's two application-invocable API functions, bf_enable_counting() and bf_tag_data_region(), can be declared and prototyped with #include <byfl/byfl.h> (a new header file).
• -bf-reuse-dist, which is now properly documented, writes a Reuse distance table to the .byfl file.
• A new -bf-strides option tracks data access strides on a per-load/store basis and writes the results to a new Strided accesses table.
• The compiler wrapper scripts honor the -M, -MD, -MM, -MMD, and -MP preprocessor options.
• The Functions and Called functions tables include function file names and line numbers.
• A new bfbin2hpctk postprocessor converts .byfl files (specifically, the Functions table) to an HPCToolkit database directory. The hpcviewer GUI can be used to view the database and show Byfl data side-by-side with hardware performance counter data.
• A new side effect of the -bf-by-func option is that the Program table will report inferred in addition to observed function returns. The former is defined as the number of calls to non-Byfl-instrumented functions, and the latter is the number of Ret instructions executed by Byfl-instrumented functions.
• A new bfbin2cgrind postprocessor converts .byfl files (specifically, the Functions table) into Callgrind format, suitable for visualization and interactive exploration with KCachegrind.

Byfl v1.4 for LLVM/Clang v3.6.2

Byfl has improved a lot since version 1.3. Here are some of the highlights from the long list of changes:

• -bf-data-structs logs data-structure lifetimes.
• Applications can invoke bf_enable_counting() explicitly to dynamically enable and disable most Byfl run-time functionality. This can be used, for example, to instrument only a single iteration of a critical loop.
• Byfl's two application-invocable API functions, bf_enable_counting() and bf_tag_data_region(), can be declared and prototyped with #include <byfl/byfl.h> (a new header file).
• -bf-reuse-dist, which is now properly documented, writes a Reuse distance table to the .byfl file.
• A new -bf-strides option tracks data access strides on a per-load/store basis and writes the results to a new Strided accesses table.
• The compiler wrapper scripts honor the -M, -MD, -MM, -MMD, and -MP preprocessor options.
• The Functions and Called functions tables include function file names and line numbers.
• A new bfbin2hpctk postprocessor converts .byfl files (specifically, the Functions table) to an HPCToolkit database directory. The hpcviewer GUI can be used to view the database and show Byfl data side-by-side with hardware performance counter data.
• A new side effect of the -bf-by-func option is that the Program table will report inferred in addition to observed function returns. The former is defined as the number of calls to non-Byfl-instrumented functions, and the latter is the number of Ret instructions executed by Byfl-instrumented functions.
• A new bfbin2cgrind postprocessor converts .byfl files (specifically, the Functions table) into Callgrind format, suitable for visualization and interactive exploration with KCachegrind.

Byfl v1.4 for LLVM/Clang/DragonEgg v3.5.2

Byfl has improved a lot since version 1.3. Here are some of the highlights from the long list of changes:

• -bf-data-structs logs data-structure lifetimes.
• Applications can invoke bf_enable_counting() explicitly to dynamically enable and disable most Byfl run-time functionality. This can be used, for example, to instrument only a single iteration of a critical loop.
• Byfl's two application-invocable API functions, bf_enable_counting() and bf_tag_data_region(), can be declared and prototyped with #include <byfl/byfl.h> (a new header file).
• -bf-reuse-dist, which is now properly documented, writes a Reuse distance table to the .byfl file.
• A new -bf-strides option tracks data access strides on a per-load/store basis and writes the results to a new Strided accesses table.
• The compiler wrapper scripts honor the -M, -MD, -MM, -MMD, and -MP preprocessor options.
• The Functions and Called functions tables include function file names and line numbers.
• A new bfbin2hpctk postprocessor converts .byfl files (specifically, the Functions table) to an HPCToolkit database directory. The hpcviewer GUI can be used to view the database and show Byfl data side-by-side with hardware performance counter data.
• A new side effect of the -bf-by-func option is that the Program table will report inferred in addition to observed function returns. The former is defined as the number of calls to non-Byfl-instrumented functions, and the latter is the number of Ret instructions executed by Byfl-instrumented functions.
• A new bfbin2cgrind postprocessor converts .byfl files (specifically, the Functions table) into Callgrind format, suitable for visualization and interactive exploration with KCachegrind.

Byfl v1.3 for LLVM/Clang v3.6.2

There have been a lot of changes since the last release of Byfl. The most major change is that there is no longer a build dependency on libbfd. Instead, symbol names are determined at compile time by reading LLVM's debug metadata. Other changes include support for building on OS X, a new -bf-inst-deps option that tracks instruction dependencies (i.e., which instructions' output serves as which other instructions' input?), and the output of a new "System information" table, which includes begin and end time stamps for the run.

Byfl v1.3 for LLVM/Clang/DragonEgg v3.5.2

Given the amount of Fortran code I work with, I decided to keep Byfl's llvm-3.5 branch alive, despite LLVM 3.5 not being the most recent release of LLVM.

There have been a lot of changes since the last release of Byfl. The most major change is that there is no longer a build dependency on libbfd. Instead, symbol names are determined at compile time by reading LLVM's debug metadata. Other changes include support for building on OS X, a new -bf-inst-deps option that tracks instruction dependencies (i.e., which instructions' output serves as which other instructions' input?), and the output of a new "System information" table, which includes begin and end time stamps for the run.

Byfl v1.3 for LLVM/Clang/DragonEgg v3.5.1

Given the amount of Fortran code I work with, I decided to keep Byfl's llvm-3.5 branch alive, despite LLVM 3.5 not being the most recent release of LLVM.

There have been a lot of changes since the last release of Byfl. The most major change is that there is no longer a build dependency on libbfd. Instead, symbol names are determined at compile time by reading LLVM's debug metadata. Other changes include support for building on OS X, a new -bf-inst-deps option that tracks instruction dependencies (i.e., which instructions' output serves as which other instructions' input?), and the output of a new "System information" table, which includes begin and end time stamps for the run.

Byfl v1.2 for LLVM/Clang/DragonEgg v3.5.1

Most of the changes made since the last Byfl release focused on greatly improving the way Byfl tracks memory accesses by data structure (-bf-data-structs). Byfl is now substantially better at identifying data structures and associating accesses with the correct data structure. In addition, Byfl now provides bf-clang and bf-clang++ compiler wrappers and, for people who prefer pkg-config, a configuration file for that tool.

As far as I can tell, DragonEgg is a dead project. Development seems to have halted circa November 2014. DragonEgg fails to build against either GCC 4.9+ or LLVM 3.6+ (despite there being a DragonEgg 3.6 release). The last working combination appears to be revision 223694 of LLVM, Clang, and DragonEgg and version 4.8 of GCC, and that's what this revision of Byfl was tested against (as well as LLVM/Clang/DragonEgg 3.5.1 and LLVM/Clang 3.6). With its new support for the Clang compilers, Byfl no longer requires DragonEgg to be useful and will soon return to building against LLVM trunk. Furthermore, because LLVM 3.6 is out, Byfl's llvm-3.5 branch will be largely frozen.

The important implication is that this is likely to be the last Byfl release that supports Fortran and Go until either DragonEgg development resumes or LLVM-based compilers for Fortran and Go appear on the scene.

Byfl v1.1 for LLVM/Clang/DragonEgg v3.5.1

There have been lots of changes to Byfl since the v1.0 release. If you've been running v1.0, you should definitely upgrade to v1.1 to take advantage of all the exciting new features.

The byfl-1.1-llvm-3.5.1.tar.gz release tarball listed below has been tested with LLVM, Clang, and DragonEgg v3.5.1 although it should also work with v3.5.0. Furthermore, it should work with LLVM and Clang v3.6, but DragonEgg currently fails to build against LLVM v3.6.

Byfl v1.0 for LLVM/Clang/DragonEgg v3.5.0

Now that LLVM, Clang, and DragonEgg v3.5.0 are out, it makes sense to do a formal Byfl source release that builds against those. My hope is that this should represent a relatively painless Byfl installation once a user gets LLVM/Clang/DragonEgg v3.5 (and by implication, GCC v4.5+) installed.