similar to: [LLVMdev] jump threading and the stack

On Wed, 25 Jun 2008, Jay Foad wrote: > When jump threading duplicates a basic block, it can demote register > values defined in that block to the stack. This seems a bit > inefficient - is the idea that you should run mem2reg afterwards to > clean this up? > > "llvm-ld -O" runs jump threading but doesn't run any mem2reg pass > afterwards, and I've seen

Holy crap, I completely missed that. I'm sorry! That's my fault. On Sun, Feb 2, 2020 at 12:15 PM Johannes Doerfert <jdoerfert at anl.gov> wrote: > On 01/30, Karl Rehm via llvm-dev wrote: > > Since the bug report here: https://bugs.llvm.org/show_bug.cgi?id=44679 > I've > > been thinking about cases like it, such as: https://godbolt.org/z/Fwq8mn > > >

How does the code you would like to have look like? I don't see a relevant difference compared to gcc: https://godbolt.org/z/F-oah4 (clang unnecessarily introduces another temporary register, but that seems unrelated) Michael Am So., 2. Feb. 2020 um 18:24 Uhr schrieb Karl Rehm via llvm-dev <llvm-dev at lists.llvm.org>: > > Here's a better example. https://godbolt.org/z/fpTyFS

I am not convinced this is a jump-threading issue, but in the domain of ScalarEvolution. ScEv would need to find out which of the exits are taken or whether it loops infinitely. One can see that it exits after 10000 iterations, but ScalarEvolution cannot tell: https://godbolt.org/z/dCqdvv Michael Am Mo., 3. Feb. 2020 um 11:56 Uhr schrieb Karl Rehm <klrehm123 at gmail.com>: > > Well

Since the bug report here: https://bugs.llvm.org/show_bug.cgi?id=44679 I've been thinking about cases like it, such as: https://godbolt.org/z/Fwq8mn I wonder what we can do about this in a general sense. As far as I can tell, the jump threading algorithm is *really* conservative, which is one reason this isn't working as well as I'd hope; however, we don't want to produce

Wait, you used the same example as I did. I'm confused then; if ScEv is having troubles but it still gets optimized away somewhere, what do you think is doing it? On Mon, Feb 3, 2020 at 2:16 PM Karl Rehm <klrehm123 at gmail.com> wrote: > Ah, I see. I think there's something else going on here too, though. > https://godbolt.org/z/dCqdvv is optimized away but ScEv doesn't

Hello, in the implementation of some analysis, I need to change the program and then invoke Mem2Reg pass. That pass, in turn, requires other analysis, so I must use PassManager. Here's the code I ended up with: bool runOnFunction(llvm::Function& m) { visit(m); ExistingModuleProvider mp(m.getParent());

Hal Finkel wrote: > Hello, > > After investigating PR14133, I've discovered that jump threading can output self-referential instructions: > %inc.us = add nsw i32 %inc.us, 1 > > At least in the test case for that bug report, the relevant code is later deleted (perhaps it is unreachable), and so this does not cause a problem. Unfortunately, when vectorization is enabled, this

On Fri, 26 Nov 2004, Vladimir Prus wrote: > in the implementation of some analysis, I need to change the program and then > invoke Mem2Reg pass. That pass, in turn, requires other analysis, so I must Usually you want to do this at a higher level, why not just use 'opt -yourpass -mem2reg'? Alternatively, if you don't want to do that, you can build mem2reg into your pass if it

If I use the jump threading pass on the attached IR: $ opt before.ll -jump-threading -o - | llvm-dis -o after.ll a big chunk gets removed, a chunk that is actually necessary. ('before.ll' passes the test in webkit, while 'after.ll' fails) Can someone take a look ? -Argiris -------------- next part -------------- A non-text attachment was scrubbed... Name: before.ll Type:

Hi, I'm trying to autotune a good sequence of IR optimization passes and I seem to run into segfaults in opt (in LLVM5) with certain pass orderings. Is this expected behavior? If so, what would be the recommended way of determining pass dependencies so that I can encode them into the tuner? The test program can be found here: https://gist.github.com/kavon/92d153cdd54ce9b77162af3af47d4c95

Hi, While comparing the code by LLVM and GCC for some major libraries, I found that LLVM fails to apply jump threading with a method whose return type is std::pair<int, bool> (actually, any pair of 32-bit values like std::pair<bool, int> and std::pair<int, int>). For example, jump threading does not work for the if statement in func. std::pair<int, bool> callee(int v) {

Hi Hal, > After investigating PR14133, I've discovered that jump threading can output self-referential instructions: > %inc.us = add nsw i32 %inc.us, 1 such instructions are valid in unreachable basic blocks. > At least in the test case for that bug report, the relevant code is later deleted (perhaps it is unreachable), and so this does not cause a problem. Unfortunately, when

Hi, Is there any way to support either stack branching or heap-allocated stack frames in llvm? What I am after is non-preemptive threading support (as in Modsim, but I have also written a small library in asm to allow this in C), where a function can "suspend" itself and resume execution later. I was excited to find llvm as I thought it would be an excellent back end for a language

On Sep 2, 2010, at 8:05 AMPDT, Argyrios Kyrtzidis wrote: > If I use the jump threading pass on the attached IR: > > $ opt before.ll -jump-threading -o - | llvm-dis -o after.ll > > a big chunk gets removed, a chunk that is actually necessary. > ('before.ll' passes the test in webkit, while 'after.ll' fails) > > Can someone take a look ? This is fixed in

Hello, After investigating PR14133, I've discovered that jump threading can output self-referential instructions: %inc.us = add nsw i32 %inc.us, 1 At least in the test case for that bug report, the relevant code is later deleted (perhaps it is unreachable), and so this does not cause a problem. Unfortunately, when vectorization is enabled, this instruction causes BBVectorize to hang. Should

Hi, I'm hitting an assertion "overlapping or duplicate fragments" in the DWARF codegen in addFragmentOffset(). This originates from a duplicated dbg.declare intrinsic, declaring the same fragment twice. The duplicated call was generated by the jump threading pass. I have a patch (see below) that removes simply such duplicates, but I'm not sure whether that is the right

Hi Björn, I don't have any answers, just more confusion. Hopefully someone else can bring some light to this. I'm also interested in dbg.declares and what the rules are regarding them since it's not very clear to me at the moment. A similar fix as yours was made for duplicate non-fragment dbg.declares in r305244 and there is a bit of discussion about it in

It is my understanding that the implementation for jump-threading in LLVM is not presently able to effectively optimize code containing a state-machine implemented using a loop + switch. This is the case, for example, with the Coremark benchmark function core_state_transition(). Bug 42313 was filed to address this in 2019: https://bugs.llvm.org/show_bug.cgi?id=42313 It appears that GCC

+ Evgeny We have a jump threading pass downstream for this that we would love to upstream. I believe Evgeny was working on exactly this, i.e. preparing it for upstreaming. ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Eli Friedman via llvm-dev <llvm-dev at lists.llvm.org> Sent: 23 September 2020 19:16 To: Phipps, Alan <a-phipps