How to record trace of assembly instructions and their corresponding timestamps of a C program on macOS?

Question

I have the following C program:

int main() {    
    float number1, number2, sum=0.;
    number1 = .5;
    number2 = .3;
    while(sum > -10000000.)
        sum -= number1 + number2;        
    printf("%f",sum);
    return 0;
}

Its corresponding assembly is as follows:

_main:                                  ; @main
    .cfi_startproc
; %bb.0:
    sub sp, sp, #16                     ; =16
    .cfi_def_cfa_offset 16
    str wzr, [sp, #12]
    str wzr, [sp]
    mov w8, #1056964608
    str w8, [sp, #8]
    mov w8, #39322
    movk    w8, #16025, lsl #16
    str w8, [sp, #4]
LBB0_1:                                 ; =>This Inner Loop Header: Depth=1
    ldr s0, [sp]
    fcvt    d0, s0
    adrp    x8, lCPI0_0@PAGE
    ldr d1, [x8, lCPI0_0@PAGEOFF]
    fcmp    d0, d1
    b.le    LBB0_3
; %bb.2:                                ;   in Loop: Header=BB0_1 Depth=1
    ldr s0, [sp, #8]
    ldr s1, [sp, #4]
    fadd    s1, s0, s1
    ldr s0, [sp]
    fsub    s0, s0, s1
    str s0, [sp]
    b   LBB0_1
LBB0_3:
    mov w0, #0
    add sp, sp, #16                     ; =16
    ret
    .cfi_endproc
                                        ; -- End function
.subsections_via_symbols

I want to analyse latency of each instructions so I'm looking for ways to obtain program counter trace.

Desired output is as follows:

0000000000 _main:                                  ; @main
0000000001  .cfi_startproc
0000000002; %bb.0:
0000000003  sub sp, sp, #16                     ; =16
0000000004  .cfi_def_cfa_offset 16
0000000005  str wzr, [sp, #12]
0000000006  str wzr, [sp]
0000000007  mov w8, #1056964608
0000000008  str w8, [sp, #8]
0000000009  mov w8, #39322
0000000010  movk    w8, #16025, lsl #16
0000000011  str w8, [sp, #4]
...

where the first columns is the timestamp either in pico/nano/microseconds.

Target system is macOS, compiler is llvm, debugger is lldb.

I don't think that you can obtain this on the real machine running the code. You need a cycle-exact emulator. Did you search for one? — the busybee, Oct 21 '22 at 08:32
@thebusybee thanks. how about just getting the runtime traces of the assembly code without cycle-counts/timestamps? — Tanay Karve, Oct 23 '22 at 22:36
Commonly a processor has no tracing/history capability. The machine code can be instrumented, for example by insertion of counting instructions at the beginning of each sequence of unbranched instructions. Some compilers can do this automatically, but it changes the runtime behavior, of course. -- What is your use case? This sounds like an [XY problem}(https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). — the busybee, Oct 24 '22 at 06:09
I wanted this for a school project to measure CPI of the machine — Tanay Karve, Oct 27 '22 at 22:32

score 1 · Accepted Answer · answered Oct 21 '22 at 08:45

There is no way to precisely measure the instruction time at the granularity of few cycles (at least not on this target architecture). Thus, you cannot measure the latency of one specific instruction unless it is a very slow one. The reason is that the best instructions used to measure the time are themselves pretty long and the processor can execute multiple instructions per cycles and in an out of order way (not to mention they are pipelined). This is especially true for the M1 processor you appear to run on. On ARM, the way to measure time seems to read the PMCCNTR based on this post. You certainly need to care about the superscalar out-of-order execution even with such instruction though. The delay taken by such instruction is dependent of the target architecture and AFAIK there is no official public information targetting the M1 on this topic (in fact, the documentation is pretty scarce on the way the M1 execute instructions so far).

An alternative solution is to simulate the execution of the code with LLVM-MCA which performs a static analysis of the program so to simulate the scheduling of the instructions on the target architecture. The static analysis has a big downside: the actual runtime behaviour of loops and conditional jumps is not considered.

Note that profiling a non-optimized code is generally a huge waste of time as it does not reflect the actual execution of the release version (which should be optimized). Once optimized, the code is likely bounded by the dependency chain on sum. This is especially true on the M1 processor which can execute a lot of instructions in parallel on a same (big/performance) core.

How to record trace of assembly instructions and their corresponding timestamps of a C program on macOS?

1 Answers1