similar to: [LLVMdev] LLVM optimization passes crash when running on second thread

On Tue, Mar 22, 2011 at 11:51 AM, Peter Zion <peter.zion at fabric-engine.com> wrote: > 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

Hi, Is it intentional that LazyValueInfo.getPredicateAt doesn't solve for the value and only takes assumptions into account? getPredicateAt gets lattice value from cache using getValueAt call: LVILatticeVal LazyValueInfoCache::getValueAt(Value *V, Instruction *CxtI) { ... LVILatticeVal Result; mergeAssumeBlockValueConstantRange(V, Result, CxtI); ... return Result; } Other

On Fri, Mar 5, 2010 at 5:53 AM, George Giorgidze <giorgidze at gmail.com> wrote: > > Hi Erick, > > Can you make the following functions available in llvm-c. > > createStandardFunctionPasses > createStandardModulePasses > createStandardLTOPasses > > Thanks in advance, George This is a little tricky, so I need some advice from the community. First off, I'm

> On Jan 23, 2017, at 10:07 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Mon, Jan 23, 2017 at 1:08 AM, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote: > This thread kinda died. I'd like to revive it. > > The new PM stuff is making excellent progress, and this is actually one of the last things to

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

Erick Tryzelaar <erick.tryzelaar <at> gmail.com> writes: > > I've pretty much finished exposing all I wanted to llvm-c and the > ocaml bindings for the soon to be released 2.7. Does anyone need any > other functions exposed before the code freeze on the 7th? > Hi Erick, Can you make the following functions available in llvm-c. createStandardFunctionPasses

I've pretty much finished exposing all I wanted to llvm-c and the ocaml bindings for the soon to be released 2.7. Does anyone need any other functions exposed before the code freeze on the 7th?

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

Михаил 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

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

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! >>

Михаил 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

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

> Date: Wed, 26 Oct 2011 11:52:50 -0700 > From: Tanya Lattner <lattner at apple.com> > Subject: [LLVMdev] Release Notes: Volunteers needed > We need some volunteers to help with the 3.0 release notes. Traditionally, Chris has been the one to go > through all the commits (6 months worth!) and come up with a concrete list of things that have changed in 3.0. > Ideally,

The opt tool uses two helpers to run passes: createStandardFunctionPasses and createStandardModulePasses. How were the passes to be instantiated by each function chosen? There are some FunctionPasses instantiated by createStandardModulePasses which is a bit counterintuitive. I see that all passes added by the user on the command line are added to "Passes" in opt, meaning they're

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

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

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

This thread kinda died. I'd like to revive it. The new PM stuff is making excellent progress, and this is actually one of the last things to clean up. On Mon, Aug 8, 2016 at 1:10 AM Sean Silva <chisophugis at gmail.com> wrote: > Thoughts? For the moment I have put in a workaround (r274457) that makes > jump-threading invalidate LVI. > > > Is everybody happy with this