search for: ompkind

...see how the process works. > One would be to work on the TODO in OpenMPOpt.cpp line 366: > // TODO: We should validate the declaration agains the types we expect. > The idea is that we match runtime calls there and we know what types > they should have (as part of their definition in OMPKinds.def). However, > for now we do not verify the types match the function we found with the > respective name. Does this make sense? > > Feel free to look around that area and ask questions you might have. > > You should also read documentation like > https://www.llvm.org/docs/...

Hello! My name is Emanuel and I am an undergraduate student from Brazil (at the University of São Paulo) wanting to participate in this years GSoC on LLVM. Specifically, on the "Improve parallelism-aware analyses and optimizations" project. I currently do research on autotuning of LLVM IR optimization passes and I am sitting for a class about parallel computing, but I have been studying

...lem. What would happen is if the name of an OpenMP runtime function was specified in the file the types wouldn't match up when it tried to find the declaration and cause an error. The solution to this was to always attempt to typecast the function type found in the module to the one defined in OMPKinds.def. There should be some debug clauses there that will tell you the types it's finding if that's the issue. Joseph Huber ________________________________ From: Geoff Levner <glevner at gmail.com> Sent: Monday, August 10, 2020 4:34 AM To: Lang Hames <lhames at gmail.com> Cc: l...

...a/SemaOpenMP.cpp > clang/lib/Sema/SemaTemplateInstantiateDecl.cpp > clang/lib/Sema/TreeTransform.h > clang/lib/Serialization/ASTWriter.cpp > clang/lib/Serialization/ASTWriterStmt.cpp > llvm/include/llvm/Frontend/OpenMP/OMPConstants.h > llvm/include/llvm/Frontend/OpenMP/OMPKinds.def > llvm/lib/CMakeLists.txt > llvm/lib/Frontend/CMakeLists.txt > llvm/lib/Frontend/LLVMBuild.txt > llvm/lib/Frontend/OpenMP/CMakeLists.txt > llvm/lib/Frontend/OpenMP/LLVMBuild.txt > llvm/lib/Frontend/OpenMP/OMPConstants.cpp > llvm/lib/LLVMBuild.txt > > __...

Hi, I have a frontend that could insert many calls to an external threading library, my problem is that would interfere with optimizations, particularly the inliner. Is there some way to do this ? I've considered leaving textual markers in function names, is that a legitimate solution ? James -------------- next part -------------- An HTML attachment was scrubbed... URL:

...lem. What would happen is if the name of an OpenMP runtime function was specified in the file the types wouldn't match up when it tried to find the declaration and cause an error. The solution to this was to always attempt to typecast the function type found in the module to the one defined in OMPKinds.def. There should be some debug clauses there that will tell you the types it's finding if that's the issue. > > > > Joseph Huber > > ________________________________ > > From: Geoff Levner <glevner at gmail.com> > > Sent: Monday, August 10, 2020 4:34 AM...

...eInstantiateDecl.cpp > > > clang/lib/Sema/TreeTransform.h > > > clang/lib/Serialization/ASTWriter.cpp > > > clang/lib/Serialization/ASTWriterStmt.cpp > > > llvm/include/llvm/Frontend/OpenMP/OMPConstants.h > > > llvm/include/llvm/Frontend/OpenMP/OMPKinds.def > > > llvm/lib/CMakeLists.txt > > > llvm/lib/Frontend/CMakeLists.txt > > > llvm/lib/Frontend/LLVMBuild.txt > > > llvm/lib/Frontend/OpenMP/CMakeLists.txt > > > llvm/lib/Frontend/OpenMP/LLVMBuild.txt > > > llvm/lib/Frontend/OpenMP...

...ang/lib/Sema/TreeTransform.h > > > > > clang/lib/Serialization/ASTWriter.cpp > > > > > clang/lib/Serialization/ASTWriterStmt.cpp > > > > > llvm/include/llvm/Frontend/OpenMP/OMPConstants.h > > > > > llvm/include/llvm/Frontend/OpenMP/OMPKinds.def > > > > > llvm/lib/CMakeLists.txt > > > > > llvm/lib/Frontend/CMakeLists.txt > > > > > llvm/lib/Frontend/LLVMBuild.txt > > > > > llvm/lib/Frontend/OpenMP/CMakeLists.txt > > > > > llvm/lib/Frontend/OpenMP/LLVMB...

...lem. What would happen is if the name of an OpenMP runtime function was specified in the file the types wouldn't match up when it tried to find the declaration and cause an error. The solution to this was to always attempt to typecast the function type found in the module to the one defined in OMPKinds.def. There should be some debug clauses there that will tell you the types it's finding if that's the issue. > >>> > >>> Joseph Huber > >>> ________________________________ > >>> From: Geoff Levner <glevner at gmail.com> > >>&g...

...lem. What would happen is if the name of an OpenMP runtime function was specified in the file the types wouldn't match up when it tried to find the declaration and cause an error. The solution to this was to always attempt to typecast the function type found in the module to the one defined in OMPKinds.def. There should be some debug clauses there that will tell you the types it's finding if that's the issue. >>>>> >>>>> Joseph Huber >>>>> ________________________________ >>>>> From: Geoff Levner <glevner at gmail.com> &gt...

...else, see for example https://youtu.be/zfiHaPaoQPc and the OpenMPOpt pass. There are multiple bigger tasks towards better offloading, one of which is described here https://github.com/llvm/llvm-project/issues/180 It might be interesting to add the transfer functions used for memory transfer to the OMPKinds.def file so they are known in the OpenMPOpt.cpp pass. Another small task would be to eliminate trivially redundant ones, that is if you have copy X from A to B directly followed by copy X from B to A, remove both. Does this make sense? Cheers, Johannes ------------------------------------...

Hi Geoff, Nothing in that backtrace leaps out at me. Based on the stack trace and description my first guess would be a clang misconfiguration rather than a JIT bug. How is that clang invocation 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,

...ata=01%7C01%7Chtobonm%40eafit.edu.co%7C2623ce41dabf4613303e08d7ce0570e7%7C99f7b55e9cbe467b8143919782918afb%7C0&amp;sdata=oOXfSmxJZCwH5BhydZMwaoO5cXe10NKladeSYh%2F8z%2FA%3D&amp;reserved=0 >> It might be interesting to add the transfer functions used for memory >> transfer to the OMPKinds.def file so they are known in the >> OpenMPOpt.cpp pass. >> Another small task would be to eliminate trivially redundant ones, >> that is if you have copy X from A to B directly followed by copy X >> from B to A, remove both. >> >> Does this make sense? >&...

...1%7C01%7Chtobonm%40eafit.edu.co%7Cec2747b9c96d4b8ddc0f08d7ce862a84%7C99f7b55e9cbe467b8143919782918afb%7C0&amp;sdata=zTnmQJZUEiXL4B2AL07ABtV8pLfiRNKWm%2BrCgskxgb0%3D&amp;reserved=0 >>> It might be interesting to add the transfer functions used for memory >>> transfer to the OMPKinds.def file so they are known in the >>> OpenMPOpt.cpp pass. >>> Another small task would be to eliminate trivially redundant ones, >>> that is if you have copy X from A to B directly followed by copy X >>> from B to A, remove both. >>> >>> Does t...

....edu.co%7C27650f5cf4e24c5920be08d7cf3c8209%7C99f7b55e9cbe467b8143919782918afb%7C0&amp;sdata=QU6c8JHe33fkyAhEKhj3%2BBQk3AiAf7BhbXhB7ny2%2Fxk%3D&amp;reserved=0 > >>>> It might be interesting to add the transfer functions used for memory > >>>> transfer to the OMPKinds.def file so they are known in the > >>>> OpenMPOpt.cpp pass. > >>>> Another small task would be to eliminate trivially redundant ones, > >>>> that is if you have copy X from A to B directly followed by copy X > >>>> from B to A, r...

...f6a772d08d7cf570a3a%7C99f7b55e9cbe467b8143919782918afb%7C0&amp;sdata=cGz5OkdMjvpWRtIkIjkKLXHj57uzPlu7BRb62eHGiJI%3D&amp;reserved=0 > >>   >>>> It might be interesting to add the transfer functions used > for memory > >>   >>>> transfer to the OMPKinds.def file so they are known in the > >>   >>>> OpenMPOpt.cpp pass. > >>   >>>> Another small task would be to eliminate trivially redundant > ones, > >>   >>>> that is if you have copy X from A to B directly followed by > co...

...67b8143919782918afb%7C0&amp;sdata=wyVbkLe8jhPzEIH6zHRwZZLdPHCKXPuXQNW%2BOhMHxv4%3D&amp;reserved=0 > >>   >>   >>>> It might be interesting to add the transfer functions used > >> for memory > >>   >>   >>>> transfer to the OMPKinds.def file so they are known in the > >>   >>   >>>> OpenMPOpt.cpp pass. > >>   >>   >>>> Another small task would be to eliminate trivially redundant > >> ones, > >>   >>   >>>> that is if you have cop...

Hi there!, As part of my application process to the next GSoC I'm working on the TODO in OpenMPOpt.cpp line 437:     // TODO: We should validate the declaration agains the types we expect.     Link: https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/IPO/OpenMPOpt.cpp#L437 I have a question. When there is a mismatch in the types (return type or argument types) between

...CVDD7HCzFVsPwSpZLOeiO5%2BMNX78sGrDd2eYJ5dWzyE%3D&amp;reserved=0 > >>   >>   >>   >>>> It might be interesting to add the transfer > functions used > >>   >> for memory > >>   >>   >>   >>>> transfer to the OMPKinds.def file so they are known > in the > >>   >>   >>   >>>> OpenMPOpt.cpp pass. > >>   >>   >>   >>>> Another small task would be to eliminate trivially > redundant > >>   >> ones, > >>   >>...