search for: cgopenmpruntim

...ion being made? Is it from inside a callback from ORC, or is it before you add your module to the JIT? -- Lang. On Mon, Aug 3, 2020 at 5:41 AM Geoff Levner <glevner at gmail.com> wrote: > Here, by the way, is the stack trace leading to the failed assertion. > Note #9: clang::CodeGen::CGOpenMPRuntime::emitForStaticFinish(). > > #0 0x00007fb70fa44870 in abort () from /usr/lib64/libc.so.6 > #1 0x00007fb70fa3c0e6 in __assert_fail_base () from /usr/lib64/libc.so.6 > #2 0x00007fb70fa3c192 in __assert_fail () from /usr/lib64/libc.so.6 > #3 0x00007fb715ca1a68 in llvm::CallInst::ini...

Greetings, Lang and other JITters, Last week I moved our Orc v2-based app from top-of-tree to the new 11.x branch, and it no longer handles C++ code containing OpenMP directives correctly. More specifically, if I JIT compile a function containing OpenMP parallel/for pragmas, using a release version of LLVM, the code compiles and seems to work, but if I try to write the module's bitcode to

...a callback from ORC, or is it before you add your module to the JIT? > > -- Lang. > > On Mon, Aug 3, 2020 at 5:41 AM Geoff Levner <glevner at gmail.com> wrote: >> >> Here, by the way, is the stack trace leading to the failed assertion. >> Note #9: clang::CodeGen::CGOpenMPRuntime::emitForStaticFinish(). >> >> #0 0x00007fb70fa44870 in abort () from /usr/lib64/libc.so.6 >> #1 0x00007fb70fa3c0e6 in __assert_fail_base () from /usr/lib64/libc.so.6 >> #2 0x00007fb70fa3c192 in __assert_fail () from /usr/lib64/libc.so.6 >> #3 0x00007fb715ca1a68 in...

...an OpenMP runtime function, can you give me a hint as to where I might find which function it is, and where it would be declared? What I am seeing in gdb is that a two-parameter function is indeed being passed two arguments, but the first argument is not of the expected type. The call originates in CGOpenMPRuntime::emitForStaticFinish(), with DKind == llvm::omp::Directive::OMPD_for, at this line: CGF.EmitRuntimeCall(OMPBuilder.getOrCreateRuntimeFunction( CGM.getModule(), OMPRTL___kmpc_for_static_fini), Args); But I don't know where to go from there......

...as to where > > I might find which function it is, and where it would be declared? > > What I am seeing in gdb is that a two-parameter function is indeed > > being passed two arguments, but the first argument is not of the > > expected type. The call originates in > > CGOpenMPRuntime::emitForStaticFinish(), with DKind == > > llvm::omp::Directive::OMPD_for, at this line: > > > > CGF.EmitRuntimeCall(OMPBuilder.getOrCreateRuntimeFunction( > > CGM.getModule(), OMPRTL___kmpc_for_static_fini), > > Arg...

...t;>> I might find which function it is, and where it would be declared? >>> What I am seeing in gdb is that a two-parameter function is indeed >>> being passed two arguments, but the first argument is not of the >>> expected type. The call originates in >>> CGOpenMPRuntime::emitForStaticFinish(), with DKind == >>> llvm::omp::Directive::OMPD_for, at this line: >>> >>> CGF.EmitRuntimeCall(OMPBuilder.getOrCreateRuntimeFunction( >>> CGM.getModule(), OMPRTL___kmpc_for_static_fini), >>>...

...nclude/clang/AST/StmtOpenMP.h > clang/include/clang/Basic/OpenMPKinds.def > clang/include/clang/Basic/OpenMPKinds.h > clang/lib/AST/CMakeLists.txt > clang/lib/AST/OpenMPClause.cpp > clang/lib/AST/StmtOpenMP.cpp > clang/lib/Basic/OpenMPKinds.cpp > clang/lib/CodeGen/CGOpenMPRuntime.cpp > clang/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp > clang/lib/CodeGen/CGStmtOpenMP.cpp > clang/lib/CodeGen/CodeGenFunction.h > clang/lib/Parse/CMakeLists.txt > clang/lib/Parse/ParseOpenMP.cpp > clang/lib/Sema/CMakeLists.txt > clang/lib/Sema/SemaOpenMP.cpp > c...

...iday, July 29, 2016 2:19 PM > To: Zachary Turner > Cc: Sean Silva; Robinson, Paul; Piotr Padlewski; llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] Upgrading to MSVC 2015 > > There are not that many people making commits to working around MSVC > 2013 as I think are claimed CGOpenMPRuntime.cpp had 4 patches this week trying to make VS2013 happy. I can tell they were because of VS2013 because the public PS4 bot has VS2015 and it didn't seem to have the same problems. Maybe it was just bad luck that we put up an internal VS2013 bot when it happened, but it has been an incredible t...

...ic/OpenMPKinds.def > > > clang/include/clang/Basic/OpenMPKinds.h > > > clang/lib/AST/CMakeLists.txt > > > clang/lib/AST/OpenMPClause.cpp > > > clang/lib/AST/StmtOpenMP.cpp > > > clang/lib/Basic/OpenMPKinds.cpp > > > clang/lib/CodeGen/CGOpenMPRuntime.cpp > > > clang/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp > > > clang/lib/CodeGen/CGStmtOpenMP.cpp > > > clang/lib/CodeGen/CodeGenFunction.h > > > clang/lib/Parse/CMakeLists.txt > > > clang/lib/Parse/ParseOpenMP.cpp > > > clang/lib/Sema/...

...6 at 6:47 PM, Arpith C Jacob <acjacob at us.ibm.com> wrote: > Hi Dounia, > > I work on the NVPTX OpenMP codegen support and we don't use fork() but I > can point you to where you may be able to find this information. > > In the clang sources, have a look at: lib/CodeGen/CGOpenMPRuntime.cpp and > the function createRuntimeFunction where the call to __kmpc_fork_call() is > created. The type of the outlined function can be had through the function: > getKmpc_MicroPointerTy(). Is this what you are looking for? > > Regards, > Arpith > > "Openmp-dev"...

...clang/Basic/OpenMPKinds.h > > > > > clang/lib/AST/CMakeLists.txt > > > > > clang/lib/AST/OpenMPClause.cpp > > > > > clang/lib/AST/StmtOpenMP.cpp > > > > > clang/lib/Basic/OpenMPKinds.cpp > > > > > clang/lib/CodeGen/CGOpenMPRuntime.cpp > > > > > clang/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp > > > > > clang/lib/CodeGen/CGStmtOpenMP.cpp > > > > > clang/lib/CodeGen/CodeGenFunction.h > > > > > clang/lib/Parse/CMakeLists.txt > > > > > clang/lib/Pars...

...;> To: Zachary Turner >> Cc: Sean Silva; Robinson, Paul; Piotr Padlewski; llvm-dev at lists.llvm.org >> Subject: Re: [llvm-dev] Upgrading to MSVC 2015 >> >> There are not that many people making commits to working around MSVC >> 2013 as I think are claimed > > CGOpenMPRuntime.cpp had 4 patches this week trying to make VS2013 happy. > I can tell they were because of VS2013 because the public PS4 bot has > VS2015 and it didn't seem to have the same problems. Hmmm, I don't see any mention in the code itself about changes to appease MSVC 2013, so that's...

...: Sean Silva; Robinson, Paul; Piotr Padlewski; llvm- > dev at lists.llvm.org > >> Subject: Re: [llvm-dev] Upgrading to MSVC 2015 > >> > >> There are not that many people making commits to working around MSVC > >> 2013 as I think are claimed > > > > CGOpenMPRuntime.cpp had 4 patches this week trying to make VS2013 happy. > > I can tell they were because of VS2013 because the public PS4 bot has > > VS2015 and it didn't seem to have the same problems. > > Hmmm, I don't see any mention in the code itself about changes to > appease...

There are not that many people making commits to working around MSVC 2013 as I think are claimed (there are certainly a lot of commits for working around MSVC in general, however). A quick search through the code base shows there are 8 instances where we've worked around MSVC 2013 issues (there may be more that someone worked around in an ad hoc manner and did not mark). We definitely had *a

FWIW, no objections from me, after all I proposed this 3 months ago :) Probably Aaron Ballman should comment though since the primary objection last time was his. On Fri, Jul 29, 2016 at 2:00 PM Sean Silva <chisophugis at gmail.com> wrote: > On Fri, Jul 29, 2016 at 1:23 PM, Robinson, Paul via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> There are certainly

...e IR and not optimized away > OPT before reaching the vectorizer. > > In summary, the change would consist of: > > 1. Generate symbols declaration/definitions of the vector function > with the mangled name in the IR, and mark it with > @llvm-compiler.used. This could be done in CGOpenMPRuntime.cpp > 2. Use the attribute vector-abs-variant defined in this RFC to map > scalar names to vector ABI mangled name, and used the same redirection > mechanism for the user provided vector name. > 3. Move the “vector function signature generation” from the SVFS in LLVM to the openmp code...

...laration that needs to stay in the IR and not optimized away OPT before reaching the vectorizer. In summary, the change would consist of: 1. Generate symbols declaration/definitions of the vector function with the mangled name in the IR, and mark it with @llvm-compiler.used. This could be done in CGOpenMPRuntime.cpp 2. Use the attribute vector-abs-variant defined in this RFC to map scalar names to vector ABI mangled name, and used the same redirection mechanism for the user provided vector name. 3. Move the “vector function signature generation” from the SVFS in LLVM to the openmp code generator of the cl...

I agree with Simon. This looks good conceptually. I have minor implementation comments but that can wait till the code reviews. Sorry for the delay and thanks for working on this. Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Simon Moll <moll at cs.uni-saarland.de> Sent: Monday, June 17, 2019 10:02:58 AM To: Francesco Petrogalli; LLVM

...laration that needs to stay in the IR and not optimized away OPT before reaching the vectorizer. In summary, the change would consist of: 1. Generate symbols declaration/definitions of the vector function with the mangled name in the IR, and mark it with @llvm-compiler.used. This could be done in CGOpenMPRuntime.cpp 2. Use the attribute vector-abs-variant defined in this RFC to map scalar names to vector ABI mangled name, and used the same redirection mechanism for the user provided vector name. 3. Move the “vector function signature generation” from the SVFS in LLVM to the openmp code generator of the cl...

Please find the reply inline below On Sun, Feb 16, 2020 at 12:59 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > On Sat, Feb 15, 2020 at 10:42 AM Vinay Madhusudan via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Reply to Kiran Chandramohan: >> >> > You are welcome to participate, provide feedback and criticism to >> change the