Displaying 3 results from an estimated 3 matches for "unduplicat".
Did you mean:
unduplicate
2012 Dec 03
3
[LLVMdev] [RFC] "noclone" function attribute
...uot;noduplicate". "cloning" has other naming implications in llvm related to function bodies, but calls to a noduplicate function should not be duplicated in any way (e.g. tail duplication, loop unrolling, etc).
2) please have the llvm/Analysis/CodeMetrics.h code consider them to be unduplicatable (generalizing the containsIndirectBr bit).
3) Please change random parts of the compiler to use CodeMetrics, instead of scattering random checks for this attribute throughout the code. Anything duplicating code and not using CodeMetrics is just plain incorrect.
-Chris
2012 Dec 02
0
[LLVMdev] [RFC] "noclone" function attribute
I definitely support this.
In fact we were about to send a very similar proposal. The main difference I can see between this proposal and ours was that we named the attribute "noduplicate".
I graciously defer to James on the bikeshade color issue.
Michael
-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of James Molloy
2012 Dec 01
6
[LLVMdev] [RFC] "noclone" function attribute
Hi,
OpenCL has a "barrier" function with very specific semantics, and there is currently no analogue to model this in LLVM.
This has been touched on by the SPIR folks but I don't believe they put forward a proposal.
The barrier function is a special function that ensures that all workitems executing a kernel have executed up to that point before execution on any workitem can