similar to: [LLVMdev] LongTy in LowerInvoke.cpp

On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: >> Ah ok, in that case, the CBE should be fixed. There are other cases that >> could cause long arguments to exist on 32-bit systems. If the C compiler >> takes issue with this, it would be best to tell the CBE to emit casts to C >> (long) or something. > > Actually that's the only case I stumbled over this

On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: > Chris Lattner wrote: >> On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: >> >>> There is still one unneeded LongTy in LowerInvoke.cpp - something like >>> this pseudo-diff should probably get applied. >> >> >> What does this impact? > > This causes code like > > write(2,

On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: > There is still one unneeded LongTy in LowerInvoke.cpp - something like this > pseudo-diff should probably get applied. What does this impact? -Chris > Index: LowerInvoke.cpp > =================================================================== > RCS file: /var/cvs/llvm/llvm/lib/Transforms/Scalar/LowerInvoke.cpp,v >

All, I'm looking at the lowerinvoke pass as a starting point for getting SJLJ based exception handling working on ARM, but am having some troubles with it. When I run a simple testcase (attached) through llc and specify -enable-correct-eh-support, llc asserts on me. It appears there's been some bitrot somewhere. SelectDAGBuild and SelectionDAGISel cooperate to track landing pads

Hi Jim, > I'm looking at the lowerinvoke pass as a starting point for getting > SJLJ based exception handling working on ARM, but am having some > troubles with it. When I run a simple testcase (attached) through llc > and specify -enable-correct-eh-support, llc asserts on me. It appears > there's been some bitrot somewhere. SelectDAGBuild and >

On Apr 21, 2009, at 1:53 PM, Jim Grosbach wrote: > All, > > I'm looking at the lowerinvoke pass as a starting point for getting > SJLJ based exception handling working on ARM, but am having some > troubles with it. When I run a simple testcase (attached) through > llc and specify -enable-correct-eh-support, llc asserts on me. It > appears there's been some

Although most of the leaks I detected in LLVM were from singleton objects, there also seem to be some real leaks. One such leak (which is creating problems for me when I try to get rid of the constant singletons) seems to be a GlobalVariable created on line 145 of Transforms/Scalar/lowerInvoke.cpp -- any suggestions how I can make sure this GlobalVariable gets deleted? Actually I'm a bit

Hi, I have this call instruction to printf inserted which is causing an assertion failure. Any pointers to where I am wrong : Code Dump : Function *printFn=M.getNamedFunction(std::string("printf")); Constant *str=ConstantArray::get("Value : %d\n"); std::vector<Value *> Args(2); std::vector<Constant *> GEPIndices(2);

Hello, Jim > -enable-correct-eh-support, llc asserts on me. It appears there's been some > bitrot somewhere. Well, correct. Because many places expects exceptions to be dwarf-style. > Is it reasonable to expect that lowerinvoke is a good place to start for > doing what I'm after? I really don't think so. Since you're trying to map dwarf-based structures into sjlj

On 6 March 2014 18:09, Mark Seaborn <mseaborn at chromium.org> wrote: > LowerAtomic "lowers atomic intrinsics to non-atomic form for use in a > known non-preemptible environment". LowerInvoke strips out exception > handling by converting invokes to calls, so that landingpads, resumes, etc. > become dead and can be removed by a later pass. > > (As an aside,

Hi all, as suggested on the mailing list I have converted the updated LZO code into git, so please pull my "lzo-update" branch from git://github.com/markus-oberhumer/linux.git lzo-update You can browse the branch at https://github.com/markus-oberhumer/linux/compare/lzo-update I''d ask some official kernel maintainer for review and to push this into linux-next so that it

On Tue, Dec 21, 2004 at 03:45:33PM -0700, Sriraman Tallam wrote: > I have this call instruction to printf inserted which is causing > an assertion failure. Any pointers to where I am wrong : > > Function *printFn=M.getNamedFunction(std::string("printf")); std::string() is unnecessary here as it's implicit. > Constant *str=ConstantArray::get("Value :

Constant *strcon==ConstantArray::get("Value : %d\n"); Sorry Typo. On Tue, 21 Dec 2004, Misha Brukman wrote: > On Tue, Dec 21, 2004 at 03:45:33PM -0700, Sriraman Tallam wrote: > > I have this call instruction to printf inserted which is causing > > an assertion failure. Any pointers to where I am wrong : > > > > Function

While it is great that LLVM has an IR Verifier, its a little troublesome to use because it separates the point of detection from the source of the problem. That is, the verifier gets run on a module or function after its been built. By that point, the compiler's state has moved past the point at which the error was placed into the module or function. Trying to track down the source of the

On Wed, 18 Aug 2004, Valery A.Khamenya wrote: > the example attached I have used to prove that JIT and some visible > optimizations are really invoked. > > Proved OK. I got 30% speed-up in comparison to gcc 3.3.3 > on my Athlon XP 1500. Cool! Hey Valery, before we add this to the CVS repo, can you take a look at some of the changes I made to your HowToUseJIT example and

Markus, We are in the process of trying to make this happen. It's a matter of getting all the duckings lined up in a row. We finally resigned ourselves to the fact that we can't cvs/svn and maintain the sanity of FSF branches, Apple branches and LLVM branches. So, over the next few working days we are going to set up a nightly cron script to checkout the latest and greatest

The functions that I placed in ScalarTargetTransformInfo are functions what were used by LSR and LowerInvoke. getJumpSize and getJumpAlignment are used by LowerInvoke. Do you suggest that I remove them from TargetLowering and keep them in ScalarTargetTransformInfo ? Thanks, Nadav On Oct 9, 2012, at 5:47 PM, Evan Cheng <evan.cheng at apple.com> wrote: > Hi Nadav, > > The

I have llvm code that uses llvm::Type::UIntTy, llvm::Type::IntTy, and llvm::Type::SByteTy, but these are now removed. What should I use for their replacement. If I need to specify a size for IntTy and UIntTy, I want them to be the same size that an integer would be in C on the platform on which I'm compiling. So, if I need the sizes is their a way to fetch the size that an integer

Alastair Lynn wrote: > > From what I understand, the unwind instruction is implemented only > for the interpreter: there is a -lowerunwind pass for compiling to > other systems which will either lower unwind and invoke to setjmp/ > longjmp (slow) or turn invokes into calls and unwinds into abort()s. > Ah cheers, Alastair. That could be very useful (at least for me

Valery, First response of several. I don't know why the demo page at UIUC is unavailable but there is an enhanced copy of it running on the mirror at http://llvm.x10sys.com/demo/ if you ever need it. Running it produced the following LLVM equivalent for the C code in your example. implementation ; Functions: int %add1(int %x) { entry: %tmp.1 = add int %x, 1 ; <int> [#uses=1]