similar to: [LLVMdev] How to require ScalarEvolution analysis in a Module pass?

Guys, In this case, I wanted to hack globalopt pass to require ScalarEvolution analysis. It seems ScalarEvolution is not released after globalopt pass, and it will hold a reference to the basicblocks. Later when the function is removed(by inline pass), coredump happened: opt test.bc -mem2reg -globalopt -inline -loop-unroll -debug-pass Details -o out.bc >& log So it seems to me if a pass

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 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 Rjones, So, will we add dependency of ocaml-pcre in RHEL7.5 ? Just like the new bug you filed to add dependency of ocaml-camlp4 & ocaml-labltk ? -- 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: xchen@#S1, #virt ----- Original Message ----- > From: "Richard W.M.

I was building llvm2.9 using MinGW64 on windows, msys was 32 bit so I specified --host option for a cross compiling. Following are my configure options: ../llvm2.9/configure --prefix=/home/AutoESL/llvm-obj --host=x86_64-w64-mingw32 --disable-multilib The error: make[1]: Entering directory `/home/AutoESL/llvm-obj/lib/VMCore' make[1]: ***

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

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

Hi uRsers, when inverting a 2 by 2 matrix using solve, I encountered a error message: solve.default(sigma, tol = 1e-07) : system is computationally singular: reciprocal condition number = 1.7671e-017 and then I test the determinant of this matrix: 6.341393e-06. In my program, I have a condition block that whether a matrix is invertible like this: if(det(sigma)<1e-7) return NULL;

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 I think the 2nd for loop should be preceded by the test ... if (Idx < AS.getNumSlots()) Not sure why it doesn't fail on other platforms as it looks like it should be a genuine

On Wed, 14 May 2008, Jonathan S. Shapiro wrote: >> huh? > > Duncan asserted that there is a behavior in GlobalOpt.cpp that relies on > main being the single entry point. If he is mistaken, great. If he is > correct, a regression test case for this seems like a useful thing to > build. I'm not saying that somebody else should do it. In fact, it seems > like a fine way to

On Wed, 2008-05-14 at 14:38 -0700, Chris Lattner wrote: > On Wed, 14 May 2008, Jonathan S. Shapiro wrote: > >> huh? > > > > Duncan asserted that there is a behavior in GlobalOpt.cpp that relies on > > main being the single entry point. If he is mistaken, great. If he is > > correct, a regression test case for this seems like a useful thing to > > build.

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

Ah I see. I can't think of a way that would help users in any particular way offhand. I hadn't considered exposing it to clang users - do you think there is merit in that? James On Thu, 5 Nov 2015 at 16:08 Aaron Ballman <aaron at aaronballman.com> wrote: > On Thu, Nov 5, 2015 at 11:06 AM, James Molloy <james at jamesmolloy.co.uk> > wrote: > > Hi Aaron, > >

On Wed, Oct 15, 2008 at 8:28 AM, Chris Lattner <clattner at apple.com> wrote: >> I do think however that it's bit dangerous to combine static constants >> across compilation units. > > GCC does the same things with strings in some cases. You shouldn't > depend on this behavior if you want portable code. Combining is explicitly allowed for strings in C:

Hi Aaron, I think it must necessarily be exposed to users - clang must add it in certain circumstances for example. I don't think this is particularly different to many other attributes such as nocapture/nounwind, that are exposed to users and can be set by users in exceptional circumstances but are primarily inferred by the midend. James On Thu, 5 Nov 2015 at 16:03 Aaron Ballman <aaron

Jack Howarth wrote: > I've had better luck compiling all of pymol 1.1r2 with > -O4 on darwin9. Everythink links and there appears to be > no regressions in the resulting code. I take it that LTO > in llvm 2.5 is still limited to dead code elimination, > correct? No. libLTO does the equivalent to opt -internalize -ipsccp -globalopt -constmerge -deadargelim -instcombine

On Thu, May 1, 2014 at 11:12 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 1 May 2014 14:08, Reid Kleckner <rnk at google.com> wrote: >> 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