llvm dev - Apr 2017 - Splitting C/C++ code into pure and side-effecting code

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.


__attribute__((annotate("pure"))
int increment(int x){
    return x + 1;
}

__attribute__((annotate("pure")))
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.
    b--;
  }

  printf("%d + %d = %d\n", a, b, c)
__attribute__((annotate("call_impure")));
  // 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.

Thanks
Suman

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>

This probably a better question for the clang developer list cfe-dev.

On Sun, Apr 9, 2017 at 12:01 PM Suman Thakur via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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.
>
>
> __attribute__((annotate("pure"))
> int increment(int x){
>     return x + 1;
> }
>
> __attribute__((annotate("pure")))
> 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.
>     b--;
>   }
>
>   printf("%d + %d = %d\n", a, b, c)
> __attribute__((annotate("call_impure")));
>   // 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.
>
> Thanks
> Suman
>
> PS: I'm not subscribed to LLVM mailing list so please reply-all.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170409/78bcbfce/attachment.html>

Hi Suman,

I think you can ascertain pureness automatically leveraging the compiler
instead of manually tagging attribute to each method and call-site. It
would seem like impurity should be a transitive attribute. So this would
conflict with below.

__attribute__((annotate("pure")))
int add(uint32_t a, uint32_t b)  {    // impure by calling printf...
...
  printf("%d + %d = %d\n", a, b, c)
__attribute__((annotate("call_
impure")));

Finding purity of functions should be possible by parsing each function
across files and build up a call dag tree. You can traverse bottom-up to
mark each function as impure from callees and using the definition of
pure-ness. From there you could find two sets of functions, put them into
export files, and use them to link the two libraries as you want.

Regards,
Kevin

On Sun, Apr 9, 2017 at 12:33 PM, Craig Topper via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> This probably a better question for the clang developer list cfe-dev.
>
> On Sun, Apr 9, 2017 at 12:01 PM Suman Thakur via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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.
>>
>>
>> __attribute__((annotate("pure"))
>> int increment(int x){
>>     return x + 1;
>> }
>>
>> __attribute__((annotate("pure")))
>> 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.
>>     b--;
>>   }
>>
>>   printf("%d + %d = %d\n", a, b, c)
__attribute__((annotate("call_
>> impure")));
>>   // 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.
>>
>> Thanks
>> Suman
>>
>> PS: I'm not subscribed to LLVM mailing list so please reply-all.
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> --
> ~Craig
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170409/9c220f72/attachment.html>