llvm dev - May 2011 - [LLVMdev] llvm and openmp

Hi all,

I am new to llvm. Does llvm has support for openmp directives like #pragma
openmp threadprivate(var)? If so does the variable 'var' can be class
objects instead of Plain Old Datatypes (POD) like int, float etc. g++ allows
the #pragma openmp threadprivate(var) primitive only for the POD type.
Please check the bug link at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 . Please let me know.

Thanks,
karthik
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110504/ff0ef1d9/attachment.html>

Hi Karthik,
> I am new to llvm. Does llvm has support for openmp directives like #pragma
> openmp threadprivate(var)?
LLVM has no special support for openmp.  The LLVM front-ends that support
openmp, namely llvm-gcc and dragonegg, lower openmp constructs down to
library calls the same way GCC does.  This is no coincidence: both of those
front-ends are based on GCC and just let the GCC machinery take care of openmp.
The clang front-end does not support openmp.

  If so does the variable 'var' can be class
objects
> instead of Plain Old Datatypes (POD) like int, float etc. g++ allows the
#pragma
> openmp threadprivate(var) primitive only for the POD type. Please check the
bug
> link at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 . Please let me
know.
You are out of luck: if GCC rejects this then so will llvm-gcc and dragonegg.
That said, the GCC Ada front-end does support thread-local storage non-POD
types, so it can be done - but it jumps through a lot of hoops and the result
is not very efficient.  There's a big comment in gcc/ada/a-tasatt.adb
explaining
how it is done and why that scheme was chosen.  You may enjoy these lines from
the start of the comment:

   The following notes are provided in case someone decides the implementation
   of this package is too complicated, or too slow. Please read this before
   making any "simplifications".

Ciao, Duncan.

Hi Duncan,

Thanks for your prompt reply. Good to know that GCC ADA front end supports
this. Since I need to compile a huge c++ project, I am in need of a c++
compiler supporting thread local storage for non POD types. Intel's c++
compiler does but its non commercial license does not suit my research work.
If you know any other c++ compiler kindly let me know.

Note: apologies as I replied to your personal id instead of group

Thanks for your time,
karthik

On Wed, May 4, 2011 at 2:54 PM, Duncan Sands <baldrick at free.fr> wrote:
> Hi Karthik,
>
> > I am new to llvm. Does llvm has support for openmp directives like
> #pragma
> > openmp threadprivate(var)?
>
> LLVM has no special support for openmp.  The LLVM front-ends that support
> openmp, namely llvm-gcc and dragonegg, lower openmp constructs down to
> library calls the same way GCC does.  This is no coincidence: both of those
> front-ends are based on GCC and just let the GCC machinery take care of
> openmp.
> The clang front-end does not support openmp.
>
>  If so does the variable 'var' can be class objects
> > instead of Plain Old Datatypes (POD) like int, float etc. g++ allows
the
> #pragma
> > openmp threadprivate(var) primitive only for the POD type. Please
check
> the bug
> > link at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 . Please let
> me know.
>
> You are out of luck: if GCC rejects this then so will llvm-gcc and
> dragonegg.
> That said, the GCC Ada front-end does support thread-local storage non-POD
> types, so it can be done - but it jumps through a lot of hoops and the
> result
> is not very efficient.  There's a big comment in gcc/ada/a-tasatt.adb
> explaining
> how it is done and why that scheme was chosen.  You may enjoy these lines
> from
> the start of the comment:
>
>   The following notes are provided in case someone decides the
> implementation
>   of this package is too complicated, or too slow. Please read this before
>   making any "simplifications".
>
> Ciao, Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110504/ccf38f8b/attachment.html>