similar to: [LLVMdev] Function inline pass core dump when removing a function

Guys, What I want to do is to hack global opt pass, which needs ScalarEvolution analysis. However opt crashed saying "opt: /home/xchen/llvm/include/llvm/PassAnalysisSupport.h:242: AnalysisType& llvm::Pass::getAnalysisID(const void*, llvm::Function&) [with AnalysisType = llvm::ScalarEvolution]: Assertion `ResultPass && "Unable to find requested analysis info"'

Dump the IR before newgvn and run through opt -newgvn. It should crash. I'm not familiar with your frontend but you might want to use -mllvm -opt-bisect-limit. On Sep 17, 2017 1:06 PM, "Andrew Kelley" <superjoe30 at gmail.com> wrote: Valgrind is strictly better than address sanitizer, is that right? It runs valgrind-clean: [nix-shell:~/dev/zig/build-llvm5-debug]$ valgrind

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

When zig updated to llvm 5 we started hitting this assertion: zig: /home/andy/downloads/llvm-project/llvm/include/llvm/Support/Casting.h:106: static bool llvm::isa_impl_cl<To, const From*>::doit(const From*) [with To = llvm::Instruction; From = llvm::Value]: Assertion `Val && "isa<> used on a null pointer"' failed. I wonder if however this was caused by an

Can you please open a bug on bugzilla and attach the ir testcase? Your fix doesn't look right (just hiding the assertion failure) On Sep 17, 2017 10:45 AM, "Andrew Kelley via llvm-dev" < llvm-dev at lists.llvm.org> wrote: > What do you think about this patch? > > --- a/llvm/lib/Transforms/Scalar/NewGVN.cpp > +++ b/llvm/lib/Transforms/Scalar/NewGVN.cpp > @@

So, 90% of the time I've seen this, it was memory corruption, usually use after free. I know I fixed one after 5.0 branched. You should compile with address sanitizer enabled, and I suspect you will find the issue quicky. If not, we really need ir that reproduces it. On Sun, Sep 17, 2017, 12:27 PM Andrew Kelley via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think I forgot to

Chen, see http://llvm.org/docs/GettingStarted.html#pf_12 ...Takumi ps. Excuse me, PE+ (aka pep) means "Executable file format for WIndows x64". 2011/5/16 陈晓宇 <xychen0921 at gmail.com>: > The stack trace: > > Starting program: > C:\MinGW\msys\1.0\home\xchen\llvm-obj\lib\Target\CellSPU/../.. > /../Debug/bin/tblgen.exe -I

Consider this program: @globalSideEffect = global i32 0 define void @tobeinlined() #0 { entry: store i32 3, i32* @globalSideEffect, align 4 musttail call fastcc void @tailcallee(i32 3) ret void } define fastcc void @tailcallee(i32 %i) { entry: call void @tobeinlined() ret void } attributes #0 = { alwaysinline } Clearly, if this is processed with opt -alwaysinline, it will lead

Hi all, I am experimenting to run a pass inherited from CallGraphSCCPass. In the pass, I iterate all functions in a SCC. In each iteration, I access all arguments of a function in the following way: Function::arg_iterator PI = fun->arg_begin(), PE = fun->arg_end(); ... I have no trouble with building. However, I am troubled with "segmentation fault" when I run the pass

Hi all, I am experimenting to run a pass inherited from CallGraphSCCPass. In the pass, I iterate all functions in a SCC. In each iteration, I access all arguments of a function in the following way: Function::arg_iterator PI = fun->arg_begin(), PE = fun->arg_end(); ... I have no trouble with building. However, I am troubled with "segmentation fault" when I run the pass

Hi Rich, Does that means that all the functions provided by virt-resize will be migrated to virt-builder? Does the command virt-resize will totally be abandoned? We may need to modify all the virt-resize test cases if so. -- Thanks & Best regards, Chen Xiang Hua Raycom office Beijing (NAY), Red Hat Inc. Red Hat Telephony: 86 10 62608040 internal extension: 8388040 Team: Virt QE IRC:

Hi, I am writing a CallGraphSCCPass that uses LoopInfo which is a FunctionPass. However, doing so results in the following error. **** Unable to schedule 'Natural Loop Information' required by '......' **** Google led me to this page, where Devang Patel suggests implementing the addLowerLevelRequiredPasses in CGPassManager in a manner similar to MPPassManager.

I talked about this with Nick in person months ago, and my understanding is that GlobalOpt is also an enabling optimization that needs to run early. For example, if we can eliminate an initializer to an internal global with no other stores to it, we can propagate the result. Maybe we should run it twice. On Thu, May 1, 2014 at 11:01 AM, Rafael Espíndola < rafael.espindola at gmail.com>

In a debug build you should get a stack trace by default, which would be helpful here. I can try to repro later today, but I'm not surprised there are issues because most people I know stick with 32-bit builds even on 64-bit Windows. On Mon, Apr 29, 2013 at 4:27 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > Hi, > > > > I check-out the latest version of

See bills commit and chris's revert. Please fix. Sent from phone On Apr 29, 2013 8:41 AM, "Keith Walker" <keith.walker at arm.com> wrote: > I fell over this issue yesterday myself with lots of asserts being thrown. > > I think the issue is in lib/IR/AsmWriter.cpp:1618 in the function > AssemblyWriter::printFunction(const Function *F) > > Looking at the code

Hi, I'd like to fix PR19590, which is about llvm.global_ctors containing functions that end up being empty after optimization (which causes the linker to add useless init_array entries to the output binary). globalopt removes empty functions from llvm.global_ctors, but by the time the function becomes empty globalopt has already run and it doesn't run again. I'm wondering what the

Hi, I'm trying to use CallGraphSCCPass, but I keep getting a bus error. I can reproduce the problem quite easily using the lib/Transforms/Hello example. I simply mix in these changes: #include "llvm/CallGraphSCCPass.h" ... struct Hello : public CallGraphSCCPass { static char ID; // Pass identification, replacement for typeid Hello() : CallGraphSCCPass(&ID) {}

On Wed, 2018-02-07 at 06:20 +0000, Chandler Carruth wrote: > I've landed the patch in r324449. > > Before we merge this into two different Clang release branches and > almost immediately release one of them, I would really like someone > to confirm that this patch works well with the Linux kernel. David, > if you're up for that, it would be great. Alternatively, Guenter

Hi, I check-out the latest version of LLVM and see many failures (on Win64): ******************** 67> FAIL: LLVM :: Transforms/GlobalOpt/zeroinitializer-gep-load.ll (5518 of 7763) 67> ******************** TEST 'LLVM :: Transforms/GlobalOpt/zeroinitializer-gep-load.ll' FAILED ******************** 67> Script: 67> -- 67> W:/LLVM_org/build64/bin/Debug/opt.EXE <

Hi all: I've included below a brief description of coroutine related optimization passes and some questions/thoughts related to them. Looking forward to your feedback, comments and questions. Thank you! Roadmap: ======== 1) Get agreement on coroutine representation and overall direction. .. repeat 1) until happy http://lists.llvm.org/pipermail/llvm-dev/2016-June/100838.html (Initial)