similar to: [LLVMdev] Size/Alignment handling bug?

To figure out the size of data varaibles for my backend, I tries this code stolen from X86 backend: const TargetData& TD = m_tm.getTargetData(); unsigned size = TD.getTypeSize(initializer->getType()); However, the getTypeInfo function in TargetData.cpp contains this: case Type::VoidTyID: case Type::BoolTyID: case Type::UByteTyID: case Type::SByteTyID: Size = 1;

On Friday 26 November 2004 19:56, Chris Lattner wrote: > On Fri, 26 Nov 2004, Vladimir Prus wrote: > > in the implementation of some analysis, I need to change the program and > > then invoke Mem2Reg pass. That pass, in turn, requires other analysis, so > > I must > > Usually you want to do this at a higher level, why not just use 'opt > -yourpass -mem2reg'?

Chris Lattner wrote: > On Sat, 13 May 2006, Vladimir Prus wrote: >>> If you're interested, please try it out. >> I get this with LLVM CVS: >> Adding: >> #include "llvm/Target/TargetData.h" >> Fixed this. > > Right, thanks. > >> Chris, any change you'll make gcc4 frontend source available from some >> CVS? Then, I can

Hello, in the implementation of some analysis, I need to change the program and then invoke Mem2Reg pass. That pass, in turn, requires other analysis, so I must use PassManager. Here's the code I ended up with: bool runOnFunction(llvm::Function& m) { visit(m); ExistingModuleProvider mp(m.getParent());

On Monday 29 November 2004 19:39, Chris Lattner wrote: > > > Alternatively, if you don't want to do that, you can build mem2reg into > > > your pass if it works better. To do this, your pass needs to > > > 'addRequired' DominatorTree and DominatorFrontier, then use the > > > interfaces exposed through > > >

The gcc4 tree is in svn. We believe it should be straight forward to create a public svn image but it will be late next week before we can set it up (minimal svn experience between Chris and myself.) Cheers, -- Jim On May 15, 2006, at 3:12 AM, Vladimir Prus wrote: > Chris Lattner wrote: > >> On Sat, 13 May 2006, Vladimir Prus wrote: >>>> If you're

Chris Lattner wrote: > > Hi All, > > There's a new snapshot of llvmgcc4 available here: > > http://nondot.org/sabre/2006-05-08-llvm-gcc-4.tar.gz > > This release includes the various portability fixes contributed on > llvmdev, includes fixes to build with mainline CVS (and, thus, *requires* > mainline CVS), and includes various other bug fixes. > > If

On Fri, 26 Nov 2004, Vladimir Prus wrote: > in the implementation of some analysis, I need to change the program and then > invoke Mem2Reg pass. That pass, in turn, requires other analysis, so I must Usually you want to do this at a higher level, why not just use 'opt -yourpass -mem2reg'? Alternatively, if you don't want to do that, you can build mem2reg into your pass if it

This needs to be applied as well. Thanks, Reid. -----Forwarded Message----- > From: Morten Ofstad <morten at hue.no> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: [LLVMdev] GetElementPtr for packed types and VS build > Date: Wed, 01 Dec 2004 15:10:49 +0100 > > As I was working with packed types it became apparent that I sometimes >

On Sat, 13 May 2006, Vladimir Prus wrote: >> If you're interested, please try it out. > I get this with LLVM CVS: > Adding: > #include "llvm/Target/TargetData.h" > Fixed this. Right, thanks. > Chris, any change you'll make gcc4 frontend source available from some CVS? > Then, I can put together a script to build it every night, to make sure > things

Hi, in LLVM CVS the above methods returns pointer to TargetData. It used to return a reference before. What is semantic of 0 return value? Or returning 0 is always a bug? If so, why pointer, and not reference is returned? Thanks, Volodya

Hello, I'm getting this in debugger, where 't' is 'Type*': (gdb) p t->isPrimitiveType() $15 = false (gdb) p t->getPrimitiveID() $16 = PointerTyID (gdb) p t->getPrimitiveSize() $17 = 0 There are a couple of things that I'd like to ask. First, if isPrimitiveType() returns false, that the fact that getPrimitiveID returns reasonable value is quite

On Thu, 17 Jun 2004, Vladimir Prus wrote: > I'm getting this in debugger, where 't' is 'Type*': > > (gdb) p t->isPrimitiveType() > $15 = false > (gdb) p t->getPrimitiveID() > $16 = PointerTyID > (gdb) p t->getPrimitiveSize() > $17 = 0 > > There are a couple of things that I'd like to ask. First, if >

HI, Developers: I linked libLTO.so in $LLVMROOT/Debug/lib however, my program crashes in assertion at 149line [Pass.cpp] void RegisterPass(const PassInfo &PI) { bool Inserted = PassInfoMap.insert(std::make_pair(PI.getTypeInfo(),&PI)).second; assert(Inserted && "Pass registered multiple times!"); } i confirm that there is only one static variable

Hello, it seems the Prolog/Epilog insertion does not correctly align stack for me. Consider the PEI::calculateFrameObjectOffsets method. It only aligns the stack if FFI->hasCalls() is true. The only place where MachineFrameInfo::setHasCalls is invoked is PEI::saveCallerSavedRegisters and the value 'true' is only passed when there are instructions with opcodes equal

Hi, I have a problem getting a properly aligned stack for my LLVM backend. I've asked about this previously, but unfortunately only now could try the suggested solution. For reference, here's the original message from me: http://mail.cs.uiuc.edu/pipermail/llvmdev/2004-July/001388.html And here's reply from Chris: http://mail.cs.uiuc.edu/pipermail/llvmdev/2004-July/001390.html The

Hello, I'm considering a possibility of writing an llvm backend for my research uses. Unfortunately, I can't find much information on how do to it. I more or less understood now the C backend is implemented, but for real backend I'd need at least register allocation. I beleive there's already register allocator in LLVM and I would like to reuse it if possible. The question is

On Tuesday 22 March 2005 20:34, Chris Lattner wrote: > Can you explain the problem in more detail? Specifically the LLVM code > gneerator assumes that there is some alignment that the stack is required > to have as part of its ABI. For example, in X86 target machine, the stack > is 8-byte aligned on entry to function calls. > > What this means is that the frame info can assume

Hi! When I go to http://llvm.cs.uiuc.edu/doxygen/annotated.html and click on link for, say, "llvm::Module", I've told that the target page does not exist. Same happens for llvm::Value, and in fact everything under "llvm" namespace. Any idea what's wrong? - Volodya

The above-mentioned test contains this: long B53 = - (1LL << 53); strictly speaking, this is not correct code. The C standard says about shift: "if the value of the first operator is ... or greater than ... the width of the promoted left operand, the behaviour is underfined". Thouhts? - Volodya