[llvm-dev] Splitting C/C++ code into pure and side-effecting code

Suman Thakur via llvm-dev llvm-dev at lists.llvm.org
Sat Apr 8 14:11:33 PDT 2017

Hello folks,

I'm not a compiler expert or subscribed to this mailing list, but I have a
unique problem. I need to split a large piece of C/C++ code into two
separate libraries: one library that only has pure code (i.e., code that
doesn't require operating system interactions) and other library that can
have both pure code and side-effecting code.

I was was wondering if it's possible to achieve this by adding something
like __attribute__((annotate("pure"))) and
__attribute__((annotate("call_impure"))) and how much effort will it be to
add such a functionality. Basically, I want "pure" attribute to be sticky,
in the sense that every function that's pure, can only call pure code
unless explicitly marked inside the function to make impure call. For
example, the following code should create one library for pure code, and a
driver which has all the impure code.

int increment(int x){
    return x + 1;

int add(uint32_t a, uint32_t b)  {
  int c = a;

  /* addition via pieno arithmetic */
  while(b != 0){
    c = increment(c);  // Okay to call pure code directly.

  printf("%d + %d = %d\n", a, b, c)
  // calling impure code requires explicit annotation
  // all the arguments to the function are copied
  // and don't share the same stack as pure code
  return c;

int main(int argc, char* argvp[]){
   a = 1;
   b = 2;.
   c = add(a,b)
   printf("%d + %d = %d", a, b); // okay to call impure from impure

The call to printf in pure code should create a stub function call
printf_impure_call(), which in the impure library just calls printf.

I know very little about compilers (mathematician by training), but I will
really appreciate if someone can comment about the feasibility of this.


PS: I'm not subscribed to LLVM mailing list so please reply-all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170408/357b0f92/attachment.html>

More information about the llvm-dev mailing list