[LLVMdev] [RFC] "noclone" function attribute

[James Molloy]

Hi Krzysztof,

Yes, however this can be solved in one of two ways:

1) Fully inline the call graph for all leaf functions that call the barrier intrinsic. This is done on several implementations as standard already, and "no call stack" is a requirement for Karrenberg's algorithm at least.

2) Apply the "noclone" attribute transitively such that if a function may transitively call the barrier intrinsic, it is marked "noclone".

Either of these methods allow the user to stop LLVM "breaking their IR. I'm aware that the general case with no user help (such as force-inlining, or otherwise controlling function cloning) is a very difficult problem. My intention is that there are no corner cases *with user assistance*. Currently there is no way to stop stuff breaking *even with* user assistance! :)

Cheers,

James
________________________________________
From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of Krzysztof Parzyszek [kparzysz at codeaurora.org]
Sent: 01 December 2012 16:22
To: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] [RFC] "noclone" function attribute

On 12/1/2012 10:02 AM, James Molloy wrote:
>
> This means that cloning whole functions (CloneFunction and CloneFunctionInto) will still work [...].

Unfortunately, it won't work.

Assume all threads call foo:

foo() {
   ...
   bar(i)
   ...
}

bar(int i) {
   ...
   barrier();
   ...
}


Now, suppose that we have discovered that bar(0) can be greatly
optimized and generate a call to the specialized version, bar_0:

foo() {
   ...
   if (i == 0) bar_0();
   else        bar(i);
   ...
}


And now we have multiple threads that no longer have a common barrier.


-Krzysztof


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev