> In http://reviews.llvm.org/D10753#195190, @ABataev wrote:
>
> > 1. Why you don't want to reuse an existing clang infrastructure for TLS
> > support? I think it would be much easier and portable solution to reuse an
> > existing code, rather than inventing a new one.
>
>
> I am afraid I don't understand exactly what you mean by TLS infrastructure.
> In my understanding, creating a TLS global variable will make each thread to
> have different storage for the variable but will not cause the Ctors/Dtors to
> run when a thread is spawn by the OpenMP runtime. Therefore the OpenMP
> runtime has to be aware of which Ctors/Dtors to use to a given variable even
> if it is declared as TLS so it can run them when it creates a thread. So from
> a codegen viewpoint, the step of registering the Dtors and Ctors is still
> required, only the cache creation and look-up can be skipped. That's the
> reason why I am reusing the existing code to do the registration.
>
> It is possible, however, that I am missing some feature in clang that would
> enable the execution of the Cotrs/Dtors when threads are spawn without
> intervention of any runtime library. If so, please give me a pointer and I
> will update the patch to use that instead.
Look at file Decl.cpp, method VarDecl::getTLSKind().
I think it would be enough to modify this method to enable codegen for
threadprivates just like for TLS:
case TSCS_unspecified:
if (!hasAttr<ThreadAttr>() && (!getASTContext().getLangOpts().OpenMPUseTLS
|| !hasAttr<OMPThreadPrivateAttr>))
return TLS_None;
return getASTContext().getLangOpts().isCompatibleWithMSVC(
LangOptions::MSVC2015)
? TLS_Dynamic
: TLS_Static;
Plus you have to disable cached codegen for threadprivates if
getASTContext().getLangOpts().OpenMPUseTLS is true
http://reviews.llvm.org/D10753
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
