Coder Social home page Coder Social logo

byfl's Introduction

Byfl: Compiler-based Application Analysis

Description

Byfl helps application developers understand code performance in a hardware-independent way. The idea is that it instruments your code at compile time then gathers and reports data at run time. For example, suppose you wanted to know how many bytes are accessed by the following C code:

double array[100000][100];
volatile double sum = 0.0;

for (int row=0; row<100000; row++)
  sum += array[row][0];

Reading the hardware performance counters (e.g., using PAPI) can be misleading. The performance counters on most processors tally not the number of bytes but rather the number of cache-line accesses. Because the array is stored in row-major order, each access to array will presumably reference a different cache line while each access to sum will presumably reference the same cache line.

Byfl performs the moral equivalent of transforming the code into the following:

unsigned long int bytes accessed = 0;
double array[100000][100];
volatile double sum = 0.0;

for (int row=0; row<100000; row++) {
  sum += array[row][0];
  bytes_accessed += 3*sizeof(double);
}

In the above, one can consider the bytes_accessed variable as a "software performance counter," as it is maintained entirely by software.

In practice, however, Byfl doesn't do source-to-source transformations (unlike, for example, ROSE) as implied by the preceding code sample. Instead, it integrates into the LLVM compiler infrastructure as an LLVM compiler pass. Because Byfl instruments code in LLVM's intermediate representation (IR), not native machine code, it outputs the same counter values regardless of target architecture. In contrast, binary-instrumentation tools such as Pin may tally operations differently on different platforms.

The name "Byfl" comes from "bytes/flops". The very first version of the code counted only bytes and floating-point operations (flops).

Installation

Once you've downloaded Byfl, the usual CMake build procedure,

cd Byfl
mkdir build
cd build
cmake ..
make
make install

should work, although, depending on your LLVM/Clang installation, you may need to pass cmake some configuration options. See INSTALL.md for a more complete explanation.

Documentation

Byfl documentation is maintained in the Byfl wiki on GitHub.

Copyright and license

Triad National Security, LLC (Triad) owns the copyright to Byfl, which it identifies internally as LA-CC-12-039. The license is BSD-ish with a "modifications must be indicated" clause. See LICENSE.md for the full text.

Contact

Scott Pakin, [email protected]

A list of all contributors to Byfl is available online.

byfl's People

Contributors

aulwes avatar cmahrens avatar davidpoliakoff avatar eanger avatar junghans avatar ltang85 avatar pmccormick avatar pmcmick avatar spakin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

byfl's Issues

Byfl does not work with openmp with -bf-every-bb and -bf-reuse-dist flags.

#include <omp.h>
#include <stdio.h>

#define N 2000

int main ( ) {
  unsigned long i, sum = 0;
  printf("%lu", sum);
#pragma omp parallel for reduction(+:sum)
  for (i = 0; i < N; i++) {
    sum = sum + i;
    printf("%lu", sum);
  }

  /* all threads done */
  printf("Sum is %lu!\n", sum);
  return 0;
}

Tried to compile and run the program. But the program stopped with Aborted (core dumped).

Tried these commands:

bf-clang -fopenmp -bf-every-bb -bf-reuse-dist -o a.out pfunc.c
./a.out
Aborted (core dumped)

I also tried with each flag individually. But the issue remains.

bf-clang -fopenmp -bf-reuse-dist -o a.out psum.c
./a.out
Aborted (core dumped)

bf-clang -fopenmp -bf-every-bb -o a.out psum.c
./a.out
Segmentation fault (core dumped)

I tried with llvm-3.9.0 and llvm-6.0.0. But both failed.

Can't compile on Ubuntu 16.04

I'm seeing a compile failure on Ubuntu 16.04 with LLVM 6.0 (installed from Ubuntu packages):

/bin/bash ./libtool  --tag=CXX   --mode=link g++  -I/usr/lib/llvm-6.0/include -std=c++0x -fuse-ld=gold -Wl,--no-keep-files-mapped -Wl,--no-map-whole-files -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -ffunction-sections -fdata-sections -O2 -DNDEBUG  -fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS  -module -avoid-version -L/usr/lib/llvm-6.0/lib   -o bytesflops.la -rpath /usr/local/libexec/byfl bytesflops_la-bytesflops.lo bytesflops_la-instrument.lo bytesflops_la-helpers.lo bytesflops_la-init.lo bytesflops_la-mersennetwister.lo bytesflops_la-functionkeygen.lo bytesflops_la-symbolinfo.lo  
libtool: link: g++  -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/5/crtbeginS.o  .libs/bytesflops_la-bytesflops.o .libs/bytesflops_la-instrument.o .libs/bytesflops_la-helpers.o .libs/bytesflops_la-init.o .libs/bytesflops_la-mersennetwister.o .libs/bytesflops_la-functionkeygen.o .libs/bytesflops_la-symbolinfo.o   -L/usr/lib/llvm-6.0/lib -L/usr/lib/gcc/x86_64-linux-gnu/5 -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/5/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/5/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crtn.o  -Wl,--no-keep-files-mapped -Wl,--no-map-whole-files -O2   -Wl,-soname -Wl,bytesflops.so -o .libs/bytesflops.so
/usr/bin/ld: unrecognized option '--no-keep-files-mapped'
/usr/bin/ld: use the --help option for usage information

I notice that the above command contains the flag -fuse-ld=gold, but based on the output of libtool it looks like this isn't being passed along to the g++ command, and so it's failing to link. Is there something I need to do to make libtool happy?

Byfl 3.9 Branch does not Compile with LLVM 3.9

I am guessing that this is an LLVM IR issue?

Steps:

(1) Checkout LLVM using the 3.9 branch from the SVN
(2) Build LLVM and install
(3) Put LLVM in path and configure Byfl
(4) Run make

../../../lib/bytesflops/init.cpp: In member function ‘void bytesflops_pass::BytesFlops::track_global_variables(llvm::Module*)’:
../../../lib/bytesflops/init.cpp:140:14: error: ‘class llvm::GlobalVariable’ has no member named ‘getDebugInfo’
       gv_var.getDebugInfo(gvs);
              ^

byfl and C++11 atomics

I'm trying to use byfl for C++ code with some features from the recent revision of the standard, particularly atomics.

Here is little code snippet to illustrate the issue:

#include <iostream>
#include <atomic>
int main(int argc, char * argv[])
{
    std::atomic<int> i;
    i=5;
    std::cout<<"Hello atmoic i = "<<i<<" !\n";
    return 0;
}

If I compile it with "g++ -std=c++11 hello.cpp" command - all is fine
if I type "bf-g++ -std=c++11 hello.cpp" -the following message comes out:

blackbird@rc017[j:0,hello]$ bf-g++ -std=c++11 hello.cpp 
/tmp/hello-c7a4f9.o: In function `std::__atomic_base<int>::store(int, std::memory_order)':
/opt/gcc-4.8.3/include/c++/4.8.2/bits/atomic_base.h:474: undefined reference to `__atomic_store_4'
/tmp/hello-c7a4f9.o: In function `std::__atomic_base<int>::load(std::memory_order) const':
/opt/gcc-4.8.3/include/c++/4.8.2/bits/atomic_base.h:496: undefined reference to `__atomic_load_4'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
bf-g++: Aborting

calling bf-gcc without arguments

$ bf-gcc
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64//libbyfl.so: undefined reference to `bf_option_string'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64//libbyfl.so: undefined reference to `bf_vectors'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64//libbyfl.so: undefined reference to `bf_line_size'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64//libbyfl.so: undefined reference to `bf_max_reuse_distance'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64//libbyfl.so: undefined reference to `bf_types'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64//libbyfl.so: undefined reference to `bf_unique_bytes'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64//libbyfl.so: undefined reference to `bf_per_func'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64//libbyfl.so: undefined reference to `bf_cache_model'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64//libbyfl.so: undefined reference to `bf_tally_inst_mix'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64//libbyfl.so: undefined reference to `bf_mem_footprint'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64//libbyfl.so: undefined reference to `bf_data_structs'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64//libbyfl.so: undefined reference to `bf_call_stack'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64//libbyfl.so: undefined reference to `bf_max_set_bits'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64//libbyfl.so: undefined reference to `bf_every_bb'
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64//libbyfl.so: undefined reference to `bf_bb_merge'
x86_64-pc-linux-gnu-clang-3.5.1: error: linker command failed with exit code 1 (use -v to see invocation)
bf-gcc: Aborting

I guess one could have a better error message.

Error: duplicate keys found

I'm getting the following error with a large application I'm running. I'd be happy to send repro instructions privately, but so far I'm just not even sure where to even look for problems. Has anyone ever seen anything like this?

Fatal Error: duplicate keys found for _ZN6scitbx2af12boost_python12flex_wrapperIdN5boost6python19return_value_policyINS4_24copy_non_const_referenceENS4_21default_call_policiesEEEE10getitem_1dERNS0_5versaIdNS0_9flex_gridINS0_5smallIlLm10EEEEEEEl _ZN5boost6python6detail12caller_arityILj2EE4implIPFRdRN6scitbx2af5versaIdNS7_9flex_gridINS7_5smallIlLm10EEEEEEElENS0_19return_value_policyINS0_24copy_non_const_referenceENS0_21default_call_policiesEEENS_3mpl7vector3IS5_SE_lEEEclEP7_objectSQ_ _ZN5boost6python7objects23caller_py_function_implINS0_6detail6callerIPFRdRN6scitbx2af5versaIdNS7_9flex_gridINS7_5smallIlLm10EEEEEEElENS0_19return_value_policyINS0_24copy_non_const_referenceENS0_21default_call_policiesEEENS_3mpl7vector3IS5_SE_lEEEEEclEP7_objectSR_

(...and it continues for several pages...)

I thought the problem might be related to my use of shared libraries, and I suspected that there might be duplicate symbols included in multiple shared libraries all being loaded into the same execution. But I've tried that scenario in a smaller reproducer, and it works fine. So at the moment I don't have any ideas for what could be causing this.

For background, the application is running in Python, and Python has not been compiled with Byfl. Python loads one or more shared libraries---of which, if I'm doing things right, one and only one has been compiled with Byfl---and then runs some functions in those shared libraries. I've tested a similar scenario in my reproducer (main compiled with the system compiler, libraries compiled with Byfl) and haven't been able to get it to show any problems.

I'm on Ubuntu 16.04 with LLVM 6.0 (with the appropriate Byfl branch). I can provide repro instructions privately if desired.

Thanks.

Potential build issues and their solutions

This is a documentation issue for potential build problems.

Byfl currently requires a relatively recent release of cmake (version 3.12). On ubuntu 18.04.4 LTS, only 13.10.2 is currently available.

If you decide to use a binary distribution of cmake from the cmake website, some issues may occur:

CMake Error at CMakeLists.txt:151 (message):
  Byfl requires the llvm/IR/Instruction.def C++ header file

or

CMake Error at cmake/ByflUtilities.cmake:84 (message):
  Cannot continue without knowing the number of LLVM opcodes.
Call Stack (most recent call first):
  CMakeLists.txt:155 (tally_llvm_opcodes)

This is because cmake is not picking up the correct header path for llvm (in my case, installed from the ubuntu repository). A workaround is to add the relevant directories to your C/C++ compiler flags:

-DCMAKE_CXX_FLAGS=-I\ /usr/include/llvm-6.0 -DCMAKE_C_FLAGS=-I\ /usr/include/llvm-6.0

On my system, the include directory was /usr/include/llvm-6.0.

Remember to remove CMakeCache and CMakeFiles. Hope this helps someone in the future facing build issues.

Build error with LLVM-17

[  2%] Building CXX object lib/bytesflops/CMakeFiles/bytesflops.dir/bytesflops.cpp.o
In file included from /home/christoph/computing/Byfl/lib/bytesflops/bytesflops.cpp:9:
/home/christoph/computing/Byfl/lib/bytesflops/bytesflops.h:29:10: fatal error: llvm/Transforms/IPO/PassManagerBuilder.h: No such file or directory
   29 | #include "llvm/Transforms/IPO/PassManagerBuilder.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
gmake[2]: *** [lib/bytesflops/CMakeFiles/bytesflops.dir/build.make:76: lib/bytesflops/CMakeFiles/bytesflops.dir/bytesflops.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:372: lib/bytesflops/CMakeFiles/bytesflops.dir/all] Error 2
gmake: *** [Makefile:166: all] Error 2

-bf-by-func is not thread safe

There are data races when using the -bf-by-func Byfl instrumentation option. The race conditions happen when accessing objects in bf_incr_func_tally.

==78232==  Lock at 0x56F5AC0 was first observed
==78232==    at 0x4C2C466: mutex_lock_WRK (hg_intercepts.c:901)
==78232==    by 0x4C30201: pthread_mutex_lock (hg_intercepts.c:917)
==78232==    by 0x50E82FF: bf_acquire_mega_lock (threading.cpp:24)
==78232==    by 0x40143C: main (init.c:4)
==78232==  Location 0x56f5ac0 is 0 bytes inside global var "megalock"
==78232==  declared at threading.cpp:12
==78232== 
==78232== Possible data race during read of size 8 at 0x65CFFD0 by thread #2
==78232== Locks held: none
==78232==    at 0x50CA461: find (cachemap.h:58)
==78232==    by 0x50CA461: CachedAnyMap<std::unordered_map<unsigned long, unsigned long, std::hash<unsigned long>, 
std::equal_to<unsigned long>, std::allocator<std::pair<unsigned long const, unsigned long> > >, unsigned long, unsi
gned long, std::equal_to<unsigned long> >::operator[](unsigned long const&) (cachemap.h:113)
==78232==    by 0x50CAB67: bf_incr_func_tally (byfl.cpp:209)
==78232==    by 0x401C93: main._omp_fn.0 (init.c:9)
==78232==    by 0x591BB89: gomp_thread_start (team.c:115)
==78232==    by 0x4C2EF50: mythread_wrapper (hg_intercepts.c:389)
==78232==    by 0x56FD805: start_thread (in /lib64/libpthread-2.11.3.so)
==78232==    by 0x5E099BC: clone (in /lib64/libc-2.11.3.so)
==78232== 
==78232== This conflicts with a previous write of size 8 by thread #1
==78232== Locks held: 1, at address 0x56F5AC0
==78232==    at 0x50CA578: find (cachemap.h:88)
==78232==    by 0x50CA578: CachedAnyMap<std::unordered_map<unsigned long, unsigned long, std::hash<unsigned long>, 
std::equal_to<unsigned long>, std::allocator<std::pair<unsigned long const, unsigned long> > >, unsigned long, unsi
gned long, std::equal_to<unsigned long> >::operator[](unsigned long const&) (cachemap.h:113)
==78232==    by 0x50CAB67: bf_incr_func_tally (byfl.cpp:209)
==78232==    by 0x401EF3: main._omp_fn.0 (init.c:9)
==78232==    by 0x401629: main (init.c:9)
==78232==  Address 0x65cffd0 is 0 bytes inside a block of size 16 alloc'd
==78232==    at 0x4C29C15: operator new(unsigned long) (vg_replace_malloc.c:333)
==78232==    by 0x50CA55E: find (cachemap.h:84)
==78232==    by 0x50CA55E: CachedAnyMap<std::unordered_map<unsigned long, unsigned long, std::hash<unsigned long>, 
std::equal_to<unsigned long>, std::allocator<std::pair<unsigned long const, unsigned long> > >, unsigned long, unsi
gned long, std::equal_to<unsigned long> >::operator[](unsigned long const&) (cachemap.h:113)
==78232==    by 0x50CAB67: bf_incr_func_tally (byfl.cpp:209)
==78232==    by 0x4013EE: main (init.c:4)
==78232==  Block was alloc'd by thread #1

I am using byfl-1.5-llvm-3.5.2 and gcc-4.8.1 on Cori at NERSC. You should be able to reproduce it using:

> cat init.c
#include <stdio.h>
#define UB 10000

int main()
{
  int x[UB];
  int i, sum;

#pragma omp parallel for
  for (i=0; i<UB; i++) {
    x[i] = 1;
  }
  printf("Yay, we initialized an array. First element is %d\n", x[0]);
  return 0;
}
> export BF_OPTS="-bf-by-func -bf-thread-safe -bf-verbose"
> bf-gcc init.c -fopenmp -o init
> export OMP_NUM_THREADS=2
> valgrind --tool=helgrind --read-inline-info=yes --read-var-info=yes --check-stack-refs=yes --log-file=helgrind.out ./init

You mentioned by email that locking is handled in the Byfl function instrument.cpp. There are definitely TallyByFunction code blocks which are not protected by the "mega-lock", but I don't know which ones require the lock calls.

Integer overflow when generating -bf-mem-footprint summary data

Hello,

I have encountered the following incorrect -bf-mem-footprint data when running a Blast test problem with Byfl version c2a8038:

> egrep 'bytes \(|unique bytes$|memory accesses$' byfl.out
BYFL_SUMMARY:            84,975,095,641 bytes (67,318,805,312 loaded + 17,656,290,329 stored)
BYFL_SUMMARY:             5,793,507,641 unique bytes
BYFL_SUMMARY:             1,498,296,573 bytes cover   5.0% of memory accesses
BYFL_SUMMARY:             1,498,376,652 bytes cover  10.0% of memory accesses
BYFL_SUMMARY:             1,498,395,624 bytes cover  15.1% of memory accesses
BYFL_SUMMARY:             1,498,407,936 bytes cover  20.1% of memory accesses
BYFL_SUMMARY:             1,498,419,600 bytes cover  25.1% of memory accesses
BYFL_SUMMARY:             1,498,428,032 bytes cover  30.1% of memory accesses
BYFL_SUMMARY:             1,498,436,616 bytes cover  35.1% of memory accesses
BYFL_SUMMARY:             1,498,451,581 bytes cover  40.4% of memory accesses
BYFL_SUMMARY:             1,498,469,681 bytes cover  45.7% of memory accesses
BYFL_SUMMARY:             1,498,474,953 bytes cover  51.0% of memory accesses
BYFL_SUMMARY:             1,498,490,257 bytes cover  56.0% of memory accesses
BYFL_SUMMARY:             1,498,502,969 bytes cover  61.0% of memory accesses
BYFL_SUMMARY:             1,498,514,905 bytes cover  71.5% of memory accesses
BYFL_SUMMARY:             1,498,532,745 bytes cover  83.9% of memory accesses
BYFL_SUMMARY:             1,498,537,825 bytes cover  90.7% of memory accesses

Notice that the memory footprint data is inconsistent with the total number of unique bytes. The difference is 5793507641 - 1498537825 = 4294969816 which is approximately 2**32.

This is happening because the multiplier field of bf_addr_tally_t is overflowing when data is copied from count2mult to histogram in get_address_tally_hist in tallybytes.cpp.

  // Convert count2mult from a map to a vector.
  for (count_to_mult_t::iterator c2m_iter = count2mult.begin(); c2m_iter != count2mult.end(); c2m_iter++) {
    histogram.push_back(*c2m_iter);
    *total += c2m_iter->second;
  }

The relevant types and variables are

typedef uint32_t bytecount_t;
typedef pair<bytecount_t, bytecount_t> bf_addr_tally_t;  // Number of times a count was seen ({count, multiplier})
typedef CachedUnorderedMap<bytecount_t, uint64_t> count_to_mult_t;

vector<bf_addr_tally_t> histogram;
count_to_mult_t count2mult;               // Number of times each count was seen

After changing the multiplier field of bf_addr_tally_t to uint64_t type, the memory footprint data is consistent with the number of unique bytes:

> cat fix_integer_overflow.diff
diff -rupN Byfl/lib/byfl/byfl.h Byfl-new/lib/byfl/byfl.h
--- Byfl/lib/byfl/byfl.h    2014-10-15 17:18:26.000000000 -0700
+++ Byfl-new/lib/byfl/byfl.h    2014-10-15 17:20:08.000000000 -0700
@@ -59,7 +59,7 @@ namespace bytesflops {
   // Define a datatype for counting bytes.
   typedef uint32_t bytecount_t;
   const bytecount_t bf_max_bytecount = ~(bytecount_t)(0);  // Clamp to this value
-  typedef pair<bytecount_t, bytecount_t> bf_addr_tally_t;  // Number of times a count was seen ({count, multiplier})
+  typedef pair<bytecount_t, uint64_t> bf_addr_tally_t;  // Number of times a count was seen ({count, multiplier})

   // The following library functions are used in files other than the
   // one in which they're defined.
> egrep 'bytes \(|unique bytes$|memory accesses$' byfl.out
BYFL_SUMMARY:            84,974,977,959 bytes (67,318,680,665 loaded + 17,656,297,294 stored)
BYFL_SUMMARY:             5,793,562,361 unique bytes
BYFL_SUMMARY:             5,699,282,381 bytes cover   6.7% of memory accesses
BYFL_SUMMARY:             5,793,350,913 bytes cover  11.8% of memory accesses
BYFL_SUMMARY:             5,793,403,767 bytes cover  16.8% of memory accesses
BYFL_SUMMARY:             5,793,418,205 bytes cover  21.9% of memory accesses
BYFL_SUMMARY:             5,793,428,901 bytes cover  27.0% of memory accesses
BYFL_SUMMARY:             5,793,438,005 bytes cover  32.1% of memory accesses
BYFL_SUMMARY:             5,793,450,261 bytes cover  37.4% of memory accesses
BYFL_SUMMARY:             5,793,463,651 bytes cover  42.4% of memory accesses
BYFL_SUMMARY:             5,793,486,476 bytes cover  47.6% of memory accesses
BYFL_SUMMARY:             5,793,495,656 bytes cover  52.7% of memory accesses
BYFL_SUMMARY:             5,793,513,484 bytes cover  57.9% of memory accesses
BYFL_SUMMARY:             5,793,524,876 bytes cover  69.9% of memory accesses
BYFL_SUMMARY:             5,793,524,880 bytes cover  77.3% of memory accesses
BYFL_SUMMARY:             5,793,535,740 bytes cover  82.4% of memory accesses
BYFL_SUMMARY:             5,793,550,160 bytes cover  87.4% of memory accesses
BYFL_SUMMARY:             5,793,559,647 bytes cover  96.0% of memory accesses
BYFL_SUMMARY:             5,793,562,361 bytes cover 100.0% of memory accesses

This overflow situation will affect very few applications. It happens in Blast because it memory maps extremely large database files. In a short run many of the memory addresses will only be accessed once.

Chris

compile error with clang-3.7 sys-devel/.../instrument.cpp:159:59: error: cannot convert 'const llvm::DataLayout' to 'const llvm::DataLayout*' in initialization

/var/tmp/portage/sys-devel/byfl-1.3/work/byfl-1.3/lib/bytesflops/instrument.cpp: In member function 'void bytesflops_pass::BytesFlops::instrument_load_store(llvm::Module_, llvm::StringRef, llvm::BasicBlock::iterator&, llvm::LLVMContext&, llvm::BasicBlock::iterator&, int&)':
/var/tmp/portage/sys-devel/byfl-1.3/work/byfl-1.3/lib/bytesflops/instrument.cpp:159:59: error: cannot convert 'const llvm::DataLayout' to 'const llvm::DataLayout_' in initialization
const DataLayout* target_data = module->getDataLayout();

https://bugs.gentoo.org/show_bug.cgi?id=559872

Some object files containing embedded LLVM bitcode are not converted into native objects

I have encountered a problem with object files beginning with a dot character inside static libraries. These object files (containing embedded bitcode) are not repackaged into native objects by the convert_archive_file bf-gcc function. I am using BYFL version 005efea on Hopper at NERSC.

The fix involves adding an extra glob pattern .*.o in two places in convert_archive_file in bf-gcc:

> diff bin/bf-gcc bin-fix/bf-gcc
183c183
<     foreach my $ofile (<*.o>) {

---
>     foreach my $ofile (<.*.o *.o>) {
199c199
<     execute_command("ar", $verbosity > 0 ? "rv" : "r", $afile, glob "*.o");

---
>     execute_command("ar", $verbosity > 0 ? "rv" : "r", $afile, glob ".*.o *.o");

I encountered the error when trying to build a BYFL-enabled version of Blast (ftp://ftp.ncbi.nih.gov/blast/executables/LATEST/ncbi-blast-2.2.29+-src.tar.gz). The final link failed because many symbols were missing. One of the missing symbols was "kBlastReleaseDate".

In a GCC build this symbol is in object file .core_blast_engine.o in libxblast-static.a:

> nm -A libxblast-static.a | grep kBlastReleaseDate
libxblast-static.a:.core_blast_engine.o:0000000000000000 D kBlastReleaseDate

In my BYFL build there are no symbols in .core_blast_engine.o in libxblast-static.a, however, the original object file wrapper does contain the symbol:

> objcopy --output-target=binary --only-section=.bitcode .core_blast_engine.o .core_blast_engine.bc
> llvm-nm .core_blast_engine.bc | grep kBlastReleaseDate
         D kBlastReleaseDate

This shows that the object file conversion step in convert_archive_file is not happening for hidden files.

I've not tested, but a similar glob change is probably needed in apply_byfl_to_archive in bf-inst.

Thanks for the great tool!
Chris

Link error when using the -bf-thread-safe option

Hello,

I get an application link error when using byfl version 29fdc53 and choosing the byfl option "-bf-thread-safe". I do not get an error when I remove this option. The link error is

/scratch/scratchdirs/csdaley/hello-f1c4d2.o: In function `main':
hello.bc:(.text+0x40): undefined reference to `bf_acquire_mega_lock'
hello.bc:(.text+0x212): undefined reference to `bf_release_mega_lock'
hello.bc:(.text+0x217): undefined reference to `bf_acquire_mega_lock'
hello.bc:(.text+0x28b): undefined reference to `bf_release_mega_lock'
hello.bc:(.text+0x2b5): undefined reference to `bf_acquire_mega_lock'
hello.bc:(.text+0x4fe): undefined reference to `bf_release_mega_lock'
hello.bc:(.text+0x50f): undefined reference to `bf_acquire_mega_lock'
hello.bc:(.text+0x5ed): undefined reference to `bf_release_mega_lock'
hello.bc:(.text+0x600): undefined reference to `bf_acquire_mega_lock'
hello.bc:(.text+0x674): undefined reference to `bf_release_mega_lock'
hello.bc:(.text+0x6b0): undefined reference to `bf_acquire_mega_lock'
hello.bc:(.text+0x8f3): undefined reference to `bf_release_mega_lock'
hello.bc:(.text+0x918): undefined reference to `bf_acquire_mega_lock'
hello.bc:(.text+0xa13): undefined reference to `bf_release_mega_lock'
hello.bc:(.text+0xa3f): undefined reference to `bf_acquire_mega_lock'
hello.bc:(.text+0xb1d): undefined reference to `bf_release_mega_lock'
hello.bc:(.text+0xb2c): undefined reference to `bf_acquire_mega_lock'
hello.bc:(.text+0xbff): undefined reference to `bf_release_mega_lock'
hello.bc:(.text+0xc0d): undefined reference to `bf_acquire_mega_lock'
hello.bc:(.text+0xc9c): undefined reference to `bf_release_mega_lock'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
bf-gcc: Aborting

I am able to use this option successfully with byfl version bb3ed5f.

I'm not sure, but it may be related to commit d15378e which changed the code in init.cpp to use C function names instead of C++ function names:

     // Inject external declarations for bf_acquire_mega_lock() and
     // bf_release_mega_lock().
     if (ThreadSafety) {
-      take_mega_lock = declare_thunk(&module, "_ZN10bytesflops20bf_acquire_mega_lockEv");
-      release_mega_lock = declare_thunk(&module, "_ZN10bytesflops20bf_release_mega_lockEv");
+      take_mega_lock = declare_thunk(&module, "bf_acquire_mega_lock");
+      release_mega_lock = declare_thunk(&module, "bf_release_mega_lock");
     }

Thanks,
Chris

Byfl Branch for LLVM 3.9 does not Configure Correctly

(1) Performed the configure as required in the INSTALL documentation.

(2) Run ./configure --prefix=/home/projects/ecp-dse/tools/byfl/clang/3.9.0

(3) Output of configure is:

checking for dragonegg.so... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating include/Makefile
config.status: creating lib/Makefile
config.status: error: cannot find input file: `lib/byfl/Makefile.in'

Multiple functions can be assigned the same integer key

Hello,

I get the error "Fatal Error: duplicate keys found for counter_seconds" when running a Byfl-instrumented version of Source Extractor (http://www.astromatic.net/software/sextractor). I am using version 604cc74 of Byfl. This error does not happen in earlier versions of Byfl such as c2a8038, bb3ed5f and 005efea.

The error is produced by bf_record_key function and is happening because there are two source files in the Source Extractor package which are named misc.c: src/misc.c and src/levmar/misc.c. These files are assigned the same module identifier string "misc.opt.bc" and so have the same hash value of this string and therefore the same initial random number seed. (I can avoid the abort by renaming one of the misc.c source files in the Source Extractor package, modifying the Makefiles and rebuilding.)

Is the integer key collision worthy of a fatal error? Can the error be changed to a warning message instead? Will the collision simply lead to incorrect performance data for the functions that clash? This seems like it would not be a problem if we choose to collect performance data at program granularity only, i.e. without -bf-by-func option. One suggestion to reduce the likelihood of duplicate random number seeds is to use a string of the full path to the source file.

Thanks,
Chris

parallel make failure

make -j16
...
Making all in wrappers
make[2]: Entering directory '/var/tmp/portage/sys-devel/byfl-1.0/work/byfl-1.0_build/tools/wrappers'
cp bf-gcc bf-g++
perl /var/tmp/portage/sys-devel/byfl-1.0/work/byfl-1.0-llvm-3.5.0/tools/wrappers/make-bf-mpi mpicxx bf-g++ OMPI_CXX MPICH_CXX /usr/bin > bf-mpicxx
perl /var/tmp/portage/sys-devel/byfl-1.0/work/byfl-1.0-llvm-3.5.0/tools/wrappers/make-bf-mpi mpif90 bf-gfortran OMPI_FC MPICH_F90 /usr/bin > bf-mpif90
perl /var/tmp/portage/sys-devel/byfl-1.0/work/byfl-1.0-llvm-3.5.0/tools/wrappers/make-bf-mpi mpif77 bf-gfortran OMPI_F77 MPICH_F77 /usr/bin > bf-mpif77
test -d lib || mkdir lib
test -f lib/ParseGccOpts.pm || cp /var/tmp/portage/sys-devel/byfl-1.0/work/byfl-1.0-llvm-3.5.0/tools/wrappers/lib/ParseGccOpts.pm lib/
perl /var/tmp/portage/sys-devel/byfl-1.0/work/byfl-1.0-llvm-3.5.0/tools/wrappers/Makefile.PL \
  FIRST_MAKEFILE=wrappers.mak PREFIX=/usr \
  INSTALLMAN1DIR=/usr/share/man/man1 INSTALLMAN3DIR=/usr/share/man/man3 \
  INSTALLSITEMAN1DIR=/usr/share/man/man1 INSTALLSITEMAN3DIR=/usr/share/man/man3
Writing wrappers.mak for ParseGccOpts
Writing MYMETA.yml and MYMETA.json
/bin/echo -e 'echo-%:\n\t@echo "$($(subst echo-,,$@))"' >> wrappers.mak
perl /var/tmp/portage/sys-devel/byfl-1.0/work/byfl-1.0-llvm-3.5.0/tools/wrappers/make-bf-mpi mpicc bf-gcc OMPI_CC MPICH_CC /usr/bin > bf-mpicc
test -f Makefile.PL || cp /var/tmp/portage/sys-devel/byfl-1.0/work/byfl-1.0-llvm-3.5.0/tools/wrappers/Makefile.PL .
touch wrappers.mak
make NOECHO="" -f wrappers.mak \
  MAN1EXT=1 \
  POD2MAN='$(POD2MAN_EXE) --center=" " --release=v1.0' | uniq
make[3]: Entering directory '/var/tmp/portage/sys-devel/byfl-1.0/work/byfl-1.0_build/tools/wrappers'
/usr/bin/perl5.18.2 -MExtUtils::Command -e 'mkpath' -- blib/lib
chmod 755 blib/lib
touch blib/lib/.exists
/usr/bin/perl5.18.2 -MExtUtils::Command -e 'mkpath' -- blib/lib/auto/ParseGccOpts
chmod 755 blib/lib/auto/ParseGccOpts
touch blib/lib/auto/ParseGccOpts/.exists
/usr/bin/perl5.18.2 -MExtUtils::Command -e 'mkpath' -- blib/arch/auto/ParseGccOpts
chmod 755 blib/arch/auto/ParseGccOpts
touch blib/arch/auto/ParseGccOpts/.exists
/usr/bin/perl5.18.2 -MExtUtils::Command -e 'mkpath' -- blib/bin
chmod 755 blib/bin
touch blib/bin/.exists
/usr/bin/perl5.18.2 -MExtUtils::Command -e 'mkpath' -- blib/script
chmod 755 blib/script
touch blib/script/.exists
/usr/bin/perl5.18.2 -MExtUtils::Command -e 'mkpath' -- blib/man1
chmod 755 blib/man1
touch blib/man1/.exists
/usr/bin/perl5.18.2 -MExtUtils::Command -e 'mkpath' -- blib/man3
chmod 755 blib/man3
touch blib/man3/.exists
/usr/bin/perl5.18.2 -MExtUtils::Install -e 'pm_to_blib({@ARGV}, '\''blib/lib/auto'\'', q[], '\''755'\'')' -- \
  lib/ParseGccOpts.pm blib/lib/ParseGccOpts.pm 
cp lib/ParseGccOpts.pm blib/lib/ParseGccOpts.pm
touch pm_to_blib
true
rm -f blib/script/bf-g++
cp bf-g++ blib/script/bf-g++
/usr/bin/perl5.18.2 -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/bf-g++
chmod 755 blib/script/bf-g++
rm -f blib/script/bf-inst
cp bf-inst blib/script/bf-inst
/usr/bin/perl5.18.2 -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/bf-inst
chmod 755 blib/script/bf-inst
rm -f blib/script/bf-gfortran
cp bf-gfortran blib/script/bf-gfortran
/usr/bin/perl5.18.2 -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/bf-gfortran
chmod 755 blib/script/bf-gfortran
rm -f blib/script/bf-gcc
cp bf-gcc blib/script/bf-gcc
/usr/bin/perl5.18.2 -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/bf-gcc
chmod 755 blib/script/bf-gcc
rm -f blib/script/bf-gccgo
cp bf-gccgo blib/script/bf-gccgo
/usr/bin/perl5.18.2 -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/bf-gccgo
chmod 755 blib/script/bf-gccgo
true
/usr/bin/perl5.18.2 -MExtUtils::Command -e 'mkpath' -- blib/arch
chmod 755 blib/arch
touch blib/arch/.exists
true
/usr/bin/perl5.18.2 "-MExtUtils::Command::MM" -e pod2man "--" --center=" " --release=v1.0 --section=1 --perm_rw=644 \
  bf-gcc blib/man1/bf-gcc.1 \
  bf-inst blib/man1/bf-inst.1 
Manifying blib/man1/bf-gcc.1
Manifying blib/man1/bf-inst.1
/usr/bin/perl5.18.2 "-MExtUtils::Command::MM" -e pod2man "--" --center=" " --release=v1.0 --section=3 --perm_rw=644 \
  lib/ParseGccOpts.pm blib/man3/ParseGccOpts.3pm 
Manifying blib/man3/ParseGccOpts.3pm
true
make[3]: Leaving directory '/var/tmp/portage/sys-devel/byfl-1.0/work/byfl-1.0_build/tools/wrappers'
cp bf-gcc bf-gccgo
cp: ‘bf-gcc’ and ‘bf-gccgo’ are the same file
Makefile:532: recipe for target 'bf-gccgo' failed
make[2]: *** [bf-gccgo] Error 1

bf-clang aborts with exit code 1

I am trying to use Byfl after installing from the source code (master branch). I am using GCC 8.3.0 and LLVM 8.0.1 on an Ubuntu 18.04 machine. But when I try to compile any program with bf-clang I get the following message.

atanu@labpc:~/Installers/Byfl/Byfl/tests$ bf-clang simple.c
/usr/local/lib/libbyfl.so: undefined reference to `llvm::Value::getName() const'
clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
bf-clang: Aborting

When I use bf-clang with verbose, I get the following output:

atanu@labpc:~/Installers/Byfl/Byfl/tests$ bf-clang simple.c -v
clang version 8.0.1
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.5.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/7.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/8
Candidate multilib: .;@m64
Selected multilib: .;@m64
"/usr/local/bin/clang-8" -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name simple.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debug-info-kind=limited -dwarf-version=4 -debugger-tuning=gdb -v -resource-dir /usr/local/lib/clang/8.0.1 -internal-isystem /usr/local/include -internal-isystem /usr/local/lib/clang/8.0.1/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir /home/atanu/Installers/Byfl/Byfl/tests -ferror-limit 19 -fmessage-length 120 -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -load /usr/local/libexec/byfl/bytesflops.so -o /tmp/simple-539077.o -x c simple.c -faddrsig
clang -cc1 version 8.0.1 based upon LLVM 8.0.1 default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/local/lib/clang/8.0.1/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
"/usr/bin/ld" -z relro --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/8/crtbegin.o -L/usr/local/lib -L/usr/local/lib -L/usr/lib/gcc/x86_64-linux-gnu/8 -L/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/8/../../.. -L/usr/local/bin/../lib -L/lib -L/usr/lib /tmp/simple-539077.o -lm -rpath /usr/local/lib -lbyfl /usr/lib/gcc/x86_64-linux-gnu/8/libstdc++.so /usr/lib/x86_64-linux-gnu/libm.so /usr/lib/gcc/x86_64-linux-gnu/8/libgcc_s.so /usr/lib/gcc/x86_64-linux-gnu/8/libgcc.a /usr/lib/x86_64-linux-gnu/libc.so -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/8/crtend.o /usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crtn.o
/usr/local/lib/libbyfl.so: undefined reference to `llvm::Value::getName() const'
clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
bf-clang: Aborting

Tests fail with AMD clang 13.0.0

I use AMD Clang (Clang 13) from spack (aocc) to build Byfl and although it compiles normally, tests fail. Test 4/22 (BfClangNoOptsCompiles) fails with this error:

error: unable to load plugin 'Byfl/build_aocc/lib/bytesflops/bytesflops.so': 'Byfl/build_aocc/lib/bytesflops/bytesflops.so: undefined symbol: _ZTVN4llvm2cl6parserINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEE

If I use the default system's clang (clang 12) I do not get this error and all tests are passed.

cannot build Byfl

Hello,

I am getting compilation errors while building Byfl (errors are the same with both gcc and clang):

../../../lib/bytesflops/instrument.cpp:159:23: error: reference to type 'const llvm::DataLayout' could not bind to an rvalue of type 'const llvm::DataLayout *'
    const DataLayout& target_data = module->getDataLayout();
                      ^             ~~~~~~~~~~~~~~~~~~~~~~~
../../../lib/bytesflops/instrument.cpp:623:27: error: reference to type 'const llvm::DataLayout' could not bind to an rvalue of type 'const llvm::DataLayout *'
        const DataLayout& target_data = module->getDataLayout();
                          ^             ~~~~~~~~~~~~~~~~~~~~~~~
../../../lib/bytesflops/instrument.cpp:1014:25: error: no matching function for call to 'getGetElementPtr'
            const_ptr = ConstantExpr::getGetElementPtr(nullptr, gvar_array_str, const_ptr_indices);
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/nix/store/8hgwagcy33fywrzhcrpvfzlfqnir04wv-llvm-3.6.2/include/llvm/IR/Constants.h:1049:20: note: candidate function not viable: no known conversion from 'std::vector<Constant *>' to 'bool' for 3rd argument
  static Constant *getGetElementPtr(Constant *C, Constant *Idx,
                   ^
/nix/store/8hgwagcy33fywrzhcrpvfzlfqnir04wv-llvm-3.6.2/include/llvm/IR/Constants.h:1042:20: note: candidate function not viable: no known conversion from 'std::vector<Constant *>' to 'bool' for 3rd argument
  static Constant *getGetElementPtr(Constant *C, ArrayRef<Constant *> IdxList,
                   ^
/nix/store/8hgwagcy33fywrzhcrpvfzlfqnir04wv-llvm-3.6.2/include/llvm/IR/Constants.h:1057:20: note: candidate function not viable: no known conversion from 'std::vector<Constant *>' to 'bool' for 3rd argument
  static Constant *getGetElementPtr(Constant *C, ArrayRef<Value *> IdxList,

The reported error was generated on a x86 Linux machine using clang version 3.4.2 and llvm-config version 3.6.2
and commit 32c2ec9 of Byfl

Thank you!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.