These intrinsics are introduced for compatibility purposes. Besides MSVC GCC also supports it in its main trunk; ICC supports it on Windows and is going to support in the next version on Linux. 2013/12/18 Joerg Sonnenberger <joerg at britannica.bec.de>> On Tue, Dec 17, 2013 at 01:05:10PM -0800, David Majnemer wrote: > > This intrinsic seems very ill-defined, apparently it can be freely > > reordered and does _not_ act like a compiler barrier. [1] > > Other than source compatibility, why would one want this intrinsic? What > > semantics is it supposed to give? > > Even more, why can't it just be defined as inline function in some > header? >Does it mean that I can use inline assembler instead of implementing compiler intrinsic?> > Joerg > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Alexey Volkov Intel Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131218/8a31d2da/attachment.html>
On 18 Dec 2013, at 11:03, Alexey Volkov <avolkov.intel at gmail.com> wrote:> These intrinsics are introduced for compatibility purposes. > Besides MSVC GCC also supports it in its main trunk; ICC supports it on Windows and is going to support in the next version on Linux.There have been two questions, neither of which is really answered. The questions are: - Why does this need to be an LLVM intrinsic, rather than an inline function in a clang header expanding to some inline asm? - Given that this instruction has such poorly defined semantics that it effectively returns an arbitrary number in any function that does arithmetic, what possible benefit is there in providing it as an LLVM intrinsic? David
I don't insist on implementing LLVM intrinsic, clang header with inline asm should be enough and is much easier to implement. I am just looking for the best way to introduce this functionality to LLVM. I understand the problem with arbitrary results in some cases. Again, the main benefit here is compatibility with other compilers. Alexey. 2013/12/18 David Chisnall <David.Chisnall at cl.cam.ac.uk>> On 18 Dec 2013, at 11:03, Alexey Volkov <avolkov.intel at gmail.com> wrote: > > > These intrinsics are introduced for compatibility purposes. > > Besides MSVC GCC also supports it in its main trunk; ICC supports it on > Windows and is going to support in the next version on Linux. > > There have been two questions, neither of which is really answered. The > questions are: > > - Why does this need to be an LLVM intrinsic, rather than an inline > function in a clang header expanding to some inline asm? > > - Given that this instruction has such poorly defined semantics that it > effectively returns an arbitrary number in any function that does > arithmetic, what possible benefit is there in providing it as an LLVM > intrinsic? > > David > >-- Alexey Volkov Intel Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131218/4a191bab/attachment.html>
Reasonably Related Threads
- [LLVMdev] Intrinsics __readeflags and __writeeflags
- [LLVMdev] Intrinsics __readeflags and __writeeflags
- [LLVMdev] Intrinsics __readeflags and __writeeflags
- [LLVMdev] Intrinsics __readeflags and __writeeflags
- [LLVMdev] Intrinsics __readeflags and __writeeflags