search for: assertingvhes

While building test-suite with the new PM, I ran into problems with AssertingVH being triggered which is obvious in retrospect: https://llvm.org/bugs/show_bug.cgi?id=28400 Both cases I ran into revolve around LVI which holds AssertingVH. Essentially, what happens is this: 1. LVI holds an AssertingVH pointing at a BasicBlock 2. Some other pass ends up deleting that BB (e.g. SimplifyCFG) 3. BOOM

...an entire function, but there is no real reason that will be the case. It seems entirely plausible to nuke a basic block out from under one of these. So no, I think we need a better answer here. After thinking about this a lot, and trying and failing to implement less awful workarounds, I think AssertingVHes embedded in analysis results in fundamentally incompatible with caching of results. The cache gets invalidated automatically but not the instant the IR gets mutated. The assert happens too soon, and things blow up. I don't think we want to force cache invalidation logic in every pass that dele...

...there is no real reason that will be the case. It seems entirely plausible to nuke a basic block out from under one of these. > > So no, I think we need a better answer here. > > > After thinking about this a lot, and trying and failing to implement less awful workarounds, I think AssertingVHes embedded in analysis results in fundamentally incompatible with caching of results. > > The cache gets invalidated automatically but not the instant the IR gets mutated. The assert happens too soon, and things blow up. > > Yeah, this is the crux of the problem and clearly incompatible...

On Mon, Jul 11, 2016 at 7:51 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi Sean, > > Sean Silva wrote: > > While building test-suite with the new PM, I ran into problems with > > AssertingVH being triggered which is obvious in retrospect: > > https://llvm.org/bugs/show_bug.cgi?id=28400 > > > > Both cases I ran into revolve around LVI

Михаил wrote: > Thanks, but I replaceAllUsesWith() - works well, but I still get bug in > eraseFromParent(): > > While deleting: i32 (%class.B*, i32)* %_ZN1B1xEi > An asserting value handle still pointed to this value! > UNREACHABLE executed at /Users/neonomaly/LLVM/LLVM/lib/VMCore/Value.cpp:561! The replaceAllUsesWith + eraseFromParent pattern remains correct, but there's

Hello, I am trying to modify my LLVM-based compiler to perform an initial, no-optimization compilation synchronously on startup and then perform an asynchronous, optimized recompilation in the background, and I am getting in one of the optimization passes. - I am using the official release of LLVM 2.8 - I have compiled LLVM with threading enabled; I am running llvm::llvm_start_multithreaded() on

It is ModulePass with AnalysisUsage of CallGraph Yours sincerely, Kadysev Mikhail 22.04.2012, в 5:20, Nick Lewycky написал(а): > Михаил wrote: >> Thanks, but I replaceAllUsesWith() - works well, but I still get bug in >> eraseFromParent(): >> >> While deleting: i32 (%class.B*, i32)* %_ZN1B1xEi >> An asserting value handle still pointed to this value! >>

Hi! In some cases the use of blockaddress() crashes llc. I've attached two test-cases, one that crashes and for reference a slightly modified one (just 2 lines are commented) that works. I compile the files with # llvm-as test_crash.ll -o - | llc -f -o temp.s - and get 0 llc 0x0000000000c6ab6f 1 llc 0x0000000000c6b38d 2 libpthread.so.0 0x00007feccd2270f0 3

Thanks, but I replaceAllUsesWith() - works well, but I still get bug in eraseFromParent(): While deleting: i32 (%class.B*, i32)* %_ZN1B1xEi An asserting value handle still pointed to this value! UNREACHABLE executed at /Users/neonomaly/LLVM/LLVM/lib/VMCore/Value.cpp:561! Yours sincerely, Kadysev Mikhail 21.04.2012, в 23:45, Nick Lewycky написал(а): > Михаил wrote: >> How correctly

Михаил wrote: > It is ModulePass with AnalysisUsage of CallGraph Ah, then you'll need to update the CallGraph first. Use "CG.removeFunctionFromModule(F);" before deleting it. Nick > Yours sincerely, > Kadysev Mikhail > > 22.04.2012, в 5:20, Nick Lewycky написал(а): > >> Михаил wrote: >>> Thanks, but I replaceAllUsesWith() - works well, but I still

On 03/01/2014 21:55, Chandler Carruth wrote: > > On Tue, Nov 12, 2013 at 1:20 AM, Chris Lattner <clattner at apple.com > <mailto:clattner at apple.com>> wrote: > > n Nov 11, 2013, at 12:09 PM, Alp Toker <alp at nuanti.com > <mailto:alp at nuanti.com>> wrote: > > >> Even when you have a !NDEBUG build, the platform assert() is pretty

Hi everyone, we have several header files in which the NDEBUG macro is being used. In some of these, the NDEBUG macro changes the size, the interface, or the layout of a type. One example is AssertingVH, which turns into a flat, transparent Value* wrapper in Release build. Now everywhere you use these headers, the state of the NDEBUG flag must be the same, or else bad things could happen. This

On Jan 3, 2014, at 2:19 PM, Chandler Carruth <chandlerc at google.com> wrote: >> While having different components of LLVM and consumers of LLVM able to intermix NDEBUG and !NDEBUG built code freely without ABI issues is nice-to-have in my book, the functionality provided by AssertingVH is significantly more nice-to-have, and I don't see any easy ways to contain or limit the

On Nov 11, 2013, at 12:09 PM, Alp Toker <alp at nuanti.com> wrote: >> Even when you have a !NDEBUG build, the platform assert() is pretty >> crummy on Windows and generates, at best a UTF-16 dump, or sometimes >> just pops up a dialog. WebKit and other projects take the same approach >> and define their own assertion macros to deal with this portably. >>

On Jan 3, 2014, at 1:55 PM, Chandler Carruth <chandlerc at google.com> wrote: > > > > The key thing then is to make sure that it's safe to enable the > > assertions in the headers if an application is built with !NDEBUG and > > linked against an NDEBUG version of LLVM. > > Sounds great. I'm pretty confident that there will be no problems - in practice

On Mon, Jul 11, 2016 at 11:17 PM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Sean, > > Sean Silva wrote: > > > > But asan won't catch problems (insofar I understand how it works) if > > the free'ed BasicBlock is used as a key in a DenseMap or something -- > > if another BasicBlock gets allocated to the same location

We were successful in upgrading our JIT project to LLVM 3.0rc4 last week, after initially struggling with the various usage and IR changes from V2.9. But we have some follow-up questions: 1) In spite of building and running our tests cleanly with DEBUG+ASSERTS and RELEASE builds, we consistently see a crash when we use a DEBUG build without ASSERTs. The crash appears whenever we use the

I can confirm that the issue has been caused by NDEBUG flag. On Mon, Jul 13, 2015 at 6:29 PM Reid Kleckner <rnk at google.com> wrote: > The layout of AssertingVH has depended on NDEBUG since 2009, which > predates any of our efforts to make LLVM's ABI resilient to mismatched > NDEBUG definitions between LLVM and its users. > > For now, make sure your definition of NDEBUG

On Tue, Jul 21, 2015 at 5:55 PM Justin Bogner <mail at justinbogner.com> wrote: > Paweł Bylica <chfast at gmail.com> writes: > > I can confirm that the issue has been caused by NDEBUG flag. > > > > On Mon, Jul 13, 2015 at 6:29 PM Reid Kleckner <rnk at google.com> wrote: > > > > The layout of AssertingVH has depended on NDEBUG since 2009,

See http://llvm.org/bugs/show_bug.cgi?id=4406 The testcase at http://llvm.org/bugs/attachment.cgi?id=3141 needs to be updated to free the machine code with: ee->freeMachineCodeForFunction(cast<Function>(ll_main)); Once that's done, though, the AssertingVH is still triggered on destruction of the Module. It turns out that the stub for the external "write" is not