similar to: Fwd: bugpoint can't automatically select a safe interpreter!

TL;DR This RFC is a joint effort by Intel and Saarland University to bring the divergence analysis of the Region Vectorizer [1,2,3,4,5] (dubbed the vectorization analysis of RV) to LLVM. The implementation is available on github for feedback [0]. The existing divergence analysis infrastructure in LLVM has conceptual limitations (structured control, SCEV based). The new analysis resolves bugs

Hello, Yes? Where is allActive defined, I couldn't find it. Basically, a BB is control divergent if it's execution depends on a branch that itself depends on a divergent ssa value. On Fri, Jul 21, 2017 at 4:13 PM, Zaks, Ayal <ayal.zaks at intel.com> wrote: > What would be the definition of “isControlDivergent(BasicBlock*)”; the > complementary of “allActive(BasicBlock*)” –

Johannes, This patch seems to be causing test failures when I just do "ninja check", without running "ninja" or "ninja all" first. $ CC=clang CXX=clang++ cmake -G Ninja ~/git/llvm-project/llvm -DLLVM_USE_LINKER=lld -DLLVM_PARALLEL_LINK_JOBS=4 -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=X86 && ninja check [...] FAIL: LLVM ::

Jay, Hiroshi, did [0] resolve the problem you've seen. [0] https://github.com/llvm/llvm-project/commit/d23c61490c282a7a8f29aaa5c021cbfdaf87fb6f On 12/10, Doerfert, Johannes wrote: > I think the problem is that only clang has a dependence on the new > library and when you check LLVM without building clang it does not exist > yet. I will commit a LLVM patch today that will cause LLVM

Hi, I'm trying to build llvm (git monorepo) on Ubuntu 18.04 with EXPENSIVE_CHECKS enabled and running into various errors compiling SourceMgr.cpp, depending on which host compiler I use. For example with GCC: $ CC=gcc-8 CXX=g++-8 cmake -GNinja -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON ~/git/llvm-project/llvm/ && ninja ... [89/2690] Building CXX object

Hmm. What about the errors I quoted from using clang-7 (starting about a third of the way down my email, sorry if they got kinda lost in all the noise)? Thanks, Jay. On Tue, 3 Sep 2019 at 20:00, David Blaikie <dblaikie at gmail.com> wrote: > > Looks to me like a bug in GCC's constexpr+_GLIBCXX_CONCEPT_CHECKS support. Small test case: > > $ g++-8 test.cpp -std=c++2a

I just ran into this today. Do we need to update our requirements on libstdc++ version? Jay, did you figure out a way around this? On Wed, Sep 4, 2019 at 5:29 AM David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > It's a bug in libstdc++ - so if you have clang using libstdc++ (which it will by default, I think) then it's the same thing. You could try with

This seems to be happening to me, too. I think this happens for me on "ninja check-llvm" in a clean build. Let me know if you need more info. On Tue, Dec 10, 2019 at 2:22 PM Doerfert, Johannes via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Jay, > > I am not sure why this happens. > Can you give me some information so I can reproduce it: > Is this happens

Hello, It seems to me that our current DivergenceAnalysis does not save which BasicBlocks may suffer from divergent control. Am I correct? I want to modify our DivergenceAnalysis to add a "bool isControlDivergent(BasicBlock*) const" method and save in the divergence propagator the basicblock that are divergent. I am not sure that is entirely correct, if you have input on that please

(I work on CUDA / PTX.) For one thing I'm in favor of having fewer annotations rather than more, so if we can do this in a reasonable way without introducing the notion of co-convergent calls, I think that would be a win. The one convergent annotation is difficult enough for the GPU folks to grok and then keep in cache, and everyone who works on llvm has to pay the cost of keeping their

On 25.10.2016 16:28, Nicolai Hähnle wrote: > But I fear that this path leads to eternal fuzziness. Let me try a > completely different approach to define what we need by augmenting the > semantics of IR with "divergence tokens". In addition to its usual > value, every IR value carries a "divergence set" of divergence tokens. > > The basic rule is: the

Michael, Yes, while stepping through this VS2010 `std::swap` code, `_Move` did nothing, e.g. //////////////////////////////////////////////////// void swap(_Ty& _Left, _Ty& _Right) { // exchange values stored at _Left and _Right _Ty _Tmp = _Move(_Left); _Left = _Move(_Right); _Right = _Move(_Tmp); } //////////////////////////////////////////////////// was equivalent to:

When using MS VS2010 there is an issue with std: `SuccIterator` implements a partial assignment operator: inline const _Self &operator=(const _Self &I) { assert(Term == I.Term &&"Cannot assign iterators to two different blocks!"); idx = I.idx; return *this; } For copy construction, MS VS2010 std reserves the right, and sometimes calls, a

Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> writes: > Hi Varun, > > I'm definitely in favour of making -v more useful like this. > > On Thu, 12 Sep 2019 at 19:31, Varun Gandhi via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Option 2 (less deviation from status quo): >> -v: Adopts behavior of -vvv from Option 1. :) >> -vv: Same

On Mon, Oct 4, 2010 at 9:52 PM, Bob Floyd <bobfloyd at comcast.net> wrote: > When using MS VS2010 there is an issue with std: > > > > `SuccIterator` implements a partial assignment operator: > > > > inline const _Self &operator=(const _Self &I) { > >     assert(Term == I.Term &&"Cannot assign iterators to two different >

Hi Bob, was this issue resolved? Ciao, Duncan. > When using MS VS2010 there is an issue with std: > > `SuccIterator` implements a partial assignment operator: > > inline const _Self &operator=(const _Self &I) { > > assert(Term == I.Term &&"Cannot assign iterators to two different blocks!"); > > idx = I.idx; > > return *this; > > }

Hey all, I wanted to share a proposal <https://docs.google.com/document/d/171ecPTeXw68fbCghdGw_NPBouWvmvUX8vePlbhhHEdA/edit?usp=sharing> to revamp the current go-to IR debugging tool: Bugpoint. i'd love to hear any feedback or general thoughts. Here's the markdown version of the doc: --- # Bugpoint Redesign Author: Diego Treviño (diegotf at google.com) Date: 2016-06-05 Status:

Hi, All I want to implement DSWP Which is used for parallelization of loops. For this purpose, the loop was replaced with a new basic block in main function. And new functions were created and basic blocks of Loop assigned to them.I have checked blocks and branches for Succ and Pred relation and I have not found any problems. However I get the following error: * **opt:

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Justin > Bogner via llvm-dev > Sent: Monday, July 22, 2019 11:44 > To: Jay Foad via llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] Fwd: bugpoint can't automatically select a safe > interpreter! > > Bugpoint's user interface is notoriously

On 6/11/19 12:25 PM, Philip Reames via llvm-dev wrote: At the moment, bugpoint has three major use cases: crash reduction, miscompile reduction, and mutation fuzzing. Out of these, a huge proportion of the interface complexity comes from the miscompile handling. I generally agree with removing the auto-detection logic. I've found it to be extraordinarily error prone and confusing.