similar to: [RFC] Pass return status

Hi folks, some more information on this feature - as a reminder I started one month ago to work on an expensive check that would verify that pass return status is correctly reported by passes, i.e. no pass return « IR not modified » while actually modifying it. It took ~20 pass fixes to achieve that goal, as many passes were not respectful of that contract, but as of

> Out of curiosity, does change here include changes to names, and other semantically-irrelevant changes (e.g., changing the order of operands in a PHI)? The hashing function used to detect changes is currently very simple: it only accounts for instruction opcode and order. So some semantically-irrelevant changes are ignored (as well as some relevant changes), and some are not. Permuting two

> I agree. If a pass modifies the IR in any way, even temporarily, it was changed (at some point). I'd like to +1, but when doing the migration of the code base to enable the associated expensive check, I found situations where (B) was used. On Sat, Jul 18, 2020 at 5:20 AM Johannes Doerfert via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 7/17/20 2:57 PM, Roman

Dear all, I would like to use the PostDominatorTree in ArgPromotion. I did not find an example of how to use function level analysis inside CallGraphSCCPass. I tried to follow an example of how to use function-level pass in a module pass, but I hit "llvm_unreachable" in PMDataManager::addLowerLevelRequiredPass. What would be a proper way to make PostDominatorTree available in

I’m digging through a build failure [1], and it looks like the loop idiom recognizer adds some instructions [2], and then removes them again [3]. I don’t understand why yet, but the LegacyPassManager detects that the structural hash of the function has changed, and complains that the pass didn’t correctly report that it changed the function [4] (even though materially, it didn’t). This raises a

On Fri, Nov 30, 2018 at 03:25:10PM +0100, Serge Guelton via llvm-dev wrote: > On Thu, Feb 01, 2018 at 04:47:03PM -0500, James Y Knight via llvm-dev wrote: > > That said, I do think it could make sense to prepare llvm for the world in > > which "python" is python3 on some systems. So, I'd propose the following: > > 1. Change all #! lines to say

Looking at the InstructionCombining.cpp code: PreservedAnalyses InstCombinePass::run(Function &F,                                        AnalysisManager<Function> &AM) {   auto &AC = AM.getResult<AssumptionAnalysis>(F);   auto &DT = AM.getResult<DominatorTreeAnalysis>(F);   auto &TLI = AM.getResult<TargetLibraryAnalysis>(F);   auto *LI =

Hi folks, Python2 has reached end of support[0], and many core Python packages are dropping pthon 2 support[1]. This is a subject that raises periodically on this mlist, with a rather strong no in 2018 [-1] and a slow move in 2019 [-2, -3]. Even if Python is not a core build requirement, it's used during some configurations steps (e.g. in the cmake export_executable_symbols function), for

On Fri, Jul 17, 2020 at 10:52 PM Nikita Popov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Fri, Jul 17, 2020 at 9:30 PM Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> I’m digging through a build failure [1], and it looks like the loop idiom recognizer adds some instructions [2], and then removes them again [3]. I don’t understand

Hi folks (CCing llvm-dev, but that's probably more of a cfe-dev topic), As a follow-up to that old thread about -D_FORTIFY_SOURCE=n http://lists.llvm.org/pipermail/cfe-dev/2015-November/045845.html And, more recently, to this fedora thread where clang/llvm -D_FORTIFY_SOURCE support is claimed to be only partial: https://pagure.io/fesco/issue/2020 I dig into the glibc headers in

Hi Mikhail, As Brian noted, stuff like this works better in the new pass manager. Even in the old pass manager I thought it should work though. Did you initialize the pass, via `INITIALIZE_PASS_DEPENDENCY(PostDominatorTreeWrapperPass)`? Did you require it, via ` AU.addRequired<PostDominatorTreeWrapperPass>();`? Btw. May I ask what you are planning to do? Cheers, Johannes On 01/07,

The next LLVM social in Paris will happen on January 30th, 2018. Everyone interested in LLVM, Clang, lldb, Polly, lld, ... is invited to join. Event details, including registration (free but mandatory) at http://www.meetup.com/LLVM-Clang-social For this meetup, Adrien Guinet, Serge Guelton and Juan Manuel Martinez will talk about the "Challenges when building an LLVM bitcode

Hi Chandler, This is a high-level review of the new WIP `PassManager` infrastructure. For those that haven't dug into Chandler's commits, here's a very high-level overview (assuming IIUC): - The driver supports simple declarative syntax for specifying passes to run. E.g., `module(a,b,function(c,d),e)` runs module passes `a` and `b`, then function passes `c` and `d` for

Hi Folks, Although LLVM now relies on cmake for its build configuration, it still calls an external Python script, namely llvm-build, to manage component dependecies, activation or deactivation of target componenents and generating description for llvm-config. This system is documented in http://llvm.org/docs/CommandGuide/llvm-build.html and https://llvm.org/docs/LLVMBuild.html. Several

Hi folks, today, I wanted to concatenate two .ll, and naively typed: $ llvm-cat -help This is the not-so-helpful output I had: OVERVIEW: Module concatenation USAGE: llvm-cat [options] <input files> OPTIONS: General options: -aarch64-neon-syntax - Choose style of NEON code to emit from AArch64 backend: =generic

I am pleased to announce that LLVM 10 is now available. Get it here: https://llvm.org/releases/download.html#10.0.0 This release is the result of the LLVM community's work over the past six months (up to to e26a78e7085 on master plus commits up to d32170dbd5b on the release/10.x branch). Some highlights include: - C++ Concepts support in Clang - Clang no longer runs in a separate process

I am pleased to announce that LLVM 10 is now available. Get it here: https://llvm.org/releases/download.html#10.0.0 This release is the result of the LLVM community's work over the past six months (up to to e26a78e7085 on master plus commits up to d32170dbd5b on the release/10.x branch). Some highlights include: - C++ Concepts support in Clang - Clang no longer runs in a separate process

Hello LLVM community, For testing IR passes, LLVM currently has two kinds of tests: 1. regression tests (in llvm/test); .ll files invoking opt, and matching its text output using FileCheck. 2. unittests (in llvm/unittests); Google tests containing the IR as a string, constructing a pass pipeline, and inspecting the output using code. I propose to add an additional kind of test, which I call

On Mon, Oct 03, 2016 at 09:04:15AM +0200, Joerg Sonnenberger via llvm-dev wrote: > On Sun, Oct 02, 2016 at 11:09:08PM +0000, Zachary Turner via llvm-dev wrote: > > The BSDs don't seem as much of an issue. FreeBSD 10 and 11 both have LLVM > > 3.9 and GCC 4.9. NetBSD 6.1.5 and 7.0 both have GCC 5.3 and LLVM 3.8. > > Open BSD has a very old GCC, but distrowatch claims that

On Mon, Mar 02, 2015 at 12:12:34AM -0500, John Criswell wrote: > On 3/2/15 12:07 AM, Haopeng Liu wrote: > >Got it, thanks. But in my pass, I use function name to locate. Can I > >disable mangling in clang? > > No, but you can probably fine a library that can either mangle the original > name or demangle the name you're seeing in the LLVM bitcode. > > As an FYI,