MMichael Kruse[Polly] Insert !dbg metadata for emitted CallInsts.
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Use any_of (NFC) | 3 年前 | |
[Polly] Insert !dbg metadata for emitted CallInsts. The IR Verifier requires that every call instruction to an inlineable function (among other things, its implementation must be visible in the translation unit) must also have !dbg metadata attached to it. When parallelizing, Polly emits calls to OpenMP runtime function out of thin air, or at least not directly derived from a bounded list of previous instruction. While we could search for instructions in the SCoP that has some debug info attached to it, there is no guarantee that we find any. Our solution is to generate a new DILocation that points to line 0 to represent optimized code. The OpenMP function implementation is usually not available in the user's translation unit, but can become visible in an LTO build. For the bug to appear, libomp must also be built with debug symbols. IMHO, the IR verifier rule is too strict. Runtime functions can also be inserted by other optimization passes, such as LoopIdiomRecognize. When inserting a call to e.g. memset, it uses the DebugLoc from a StoreInst from the unoptimized code. It is not required to have !dbg metadata attached either. Fixes #56692 | 3 年前 | |
Use value instead of getValue (NFC) | 3 年前 | |
[polly][cmake] Use GNUInstallDirs to support custom installation dirs I am breaking apart D99484 so the cause of build failures is easier to understand. Reviewed By: Meinersbur Differential Revision: https://reviews.llvm.org/D117541 | 4 年前 | |
Generalize the pass registration mechanism used by Polly to any third-party tool There's quite a lot of references to Polly in the LLVM CMake codebase. However the registration pattern used by Polly could be useful to other external projects: thanks to that mechanism it would be possible to develop LLVM extension without touching the LLVM code base. This patch has two effects: 1. Remove all code specific to Polly in the llvm/clang codebase, replaicing it with a generic mechanism 2. Provide a generic mechanism to register compiler extensions. A compiler extension is similar to a pass plugin, with the notable difference that the compiler extension can be configured to be built dynamically (like plugins) or statically (like regular passes). As a result, people willing to add extra passes to clang/opt can do it using a separate code repo, but still have their pass be linked in clang/opt as built-in passes. Differential Revision: https://reviews.llvm.org/D61446 | 6 年前 | |
Remove redundaunt virtual specifiers (NFC) Identified with tidy-modernize-use-override. | 3 年前 | |
Remove redundaunt virtual specifiers (NFC) Identified with tidy-modernize-use-override. | 3 年前 | |
[Polly] Remove support for code generated by gfortran+DragonEgg. DragonEgg is not maintained anymore, hence there is no need for this functionality. Fixes llvm.org/PR52173 | 4 年前 |