[llvm-dev] LLVM Block is not the basic block

[Tim Northover via llvm-dev]

On 29 May 2018 at 13:40, Muhui Jiang via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Here you can see it obviously should not be a basic block because you called
> two functions! So the control flow graph LLVM generated is also not the real
> control flow graph, right? Do anyone know why or give me some suggestions?

The graph is designed to model all issues relevant to the compiler.
Mostly this revolves around making sure values are still live when
needed and that phi instructions work properly to merge different
values in from different paths.

In the case of function calls though, execution always returns to
precisely the next instruction with some registers defined (the return
value), some clobbered, and some memory affected. There's no real
reason to distinguish that from any similar instruction as far as the
compiler is concerned.

The case where a call can affect control-flow is when it might throw
an exception, and that's represented in LLVM IR by a different
"invoke" instruction that does describe the possible return locations.

Not to pile issues on your plate, but you should also be aware that
CodeGen can synthesize calls in some cases. For example accessing a
"thread_local" variable on Apple platforms will generate a call to
__tlv_get_address that is completely invisible in the IR. Memcpy calls
may also appear out of nowhere on most platforms.

To get something close to the CPU-level control flow graph you'd
probably have to run a very late MachineFunction pass that looked not
only at the presented basic blocks, but also checked individual
instructions for isCall[*].

Cheers.

Tim.

[*] And even that would be an abstraction. IMO there's a pretty broad,
grey spectrum when it comes to "real" control flow. Depending on what
you're doing you may or may not include segfaults, floating-point
exceptions, and even asynchronous interrupts as control flow.