similar to: [LLVMdev] ConstantExpr lowering pass for code generators

July Status Update ------------------ Hi everyone! This month has been a busy month of cleanups and refinements, and marks over a year of LLVM status updates :). LLVM is getting substantially smaller (in memory footprint) and faster, received a few cool new features, and has a few more fixed bugs. We are currently thinking about unleashing the LLVM 1.3 release in about 3-4 weeks from now. If

On Thu, 17 Jun 2004, Vladimir Prus wrote: > I'm having problems with the following LLVM instruction > > %tmp.0.i = call int (sbyte*, ...)* > %printf( sbyte* getelementptr ([11 x sbyte]* %.str_1, long 0, ...... > > The first argument in function call, > > sbyte* getelementptr ([11 x sbyte]* %.str_1..... > > appears to be ConstantExpression*, and my

Chris Lattner wrote: > > So I wonder if I can away by writing two passes which work on LLVM level. > > The first pass would extract all ConstantExpr* operands from instructions > > and move them into separate instructions. E.g. the example above would > > become: > > > > %tmp.1 = sbyte* getelementptr ([11 x sbyte]* %.str_1, .......... > > %tmp.0.i =

On Thu, 2004-07-08 at 07:07, Vladimir Prus wrote: > Vladimir Prus wrote: > > Vladimir Prus wrote: > > > 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

Chris Lattner wrote: > On Wed, 1 Mar 2006, Vladimir Prus wrote: >> I have two questions about the above method of the SelectionDAGISel >> class. >> >> 1. The overrides in PPCDAGToDAGISel and in I64DAGToDAGISel are identical >> (except for PPCISD::FIRST_NUMBER vs. IA64ISD::FIRST_NUMBER). >> Maybe, this means that it would be better if SelectionDAGISel had

Vladimir Prus wrote: > Vladimir Prus wrote: > > 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

On Fri, 4 Jun 2004, Vladimir Prus wrote: > Ok, I'm now trying to write instruction selector and have some questions > > 1. The MachineInstrBuilder has methods to add register operand and immediate > operand. However, what would be really nice is a method to add Value*. So, I > would write: > > BuildMI(*BB, NM::add, 1).add(I.getOperand(0), I.getOperand(1)); > >

On Wed, 1 Mar 2006, Vladimir Prus wrote: > I have two questions about the above method of the SelectionDAGISel class. > > 1. The overrides in PPCDAGToDAGISel and in I64DAGToDAGISel are identical > (except for PPCISD::FIRST_NUMBER vs. IA64ISD::FIRST_NUMBER). > Maybe, this means that it would be better if SelectionDAGISel had default > implementation? That would remove this code

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

On Fri, 15 Apr 2005, Vladimir Prus wrote: >> Another thing that might be interesting is the new llvm.pcmarker intrinsic >> that Andrew recently added. I have no idea if it would be useful to you >> or not, but... it's documented here: >> http://llvm.cs.uiuc.edu/docs/LangRef.html#i_pcmarker > > In fact, I'm having problems exactly while lowering the pcmarker

On Mon, 7 Jun 2004, Vladimir Prus wrote: > > Hello, > looking at X86 codegen, I see this: > > void ISel::copyConstantToRegister(MachineBasicBlock *MBB, > MachineBasicBlock::iterator IP, > Constant *C, unsigned R) { > if (ConstantExpr *CE = dyn_cast<ConstantExpr>(C)) { > ..... > case

On Wed, 2004-06-09 at 05:26, Vladimir Prus wrote: > Alkis Evlogimenos wrote: > > On Wed, 2004-06-09 at 04:56, Vladimir Prus wrote: > > > Hello! > > > Is there an (semi)automatic way to save registers used by a function? For > > > example, on my target I have to store ar0-ar4 and gr0-gr4, gr5, gr6. For > > > now I just emit huge prologue code to push

On Mon, 29 Nov 2004, Vladimir Prus wrote: > 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

On Friday 15 April 2005 18:49, Chris Lattner wrote: > On Fri, 15 Apr 2005, Vladimir Prus wrote: > > Hello, > > I just wrote the code like this: > > > > BuildMI(BB, NM::CALL, 1) > > .addExternalSymbol(("_lvksda_control_marker_" > > + > > lexical_cast<string>(bb)).c_str()); > >

On Fri, 2004-08-27 at 08:05, Vladimir Prus wrote: > Hello, > I'm getting an assertion in register allocator, specifically in > LiveIntervalAnalysis.h, method LiveIntervals::getInstructionIndex: > > unsigned getInstructionIndex(MachineInstr* instr) const { > Mi2IndexMap::const_iterator it = mi2iMap_.find(instr); > assert(it != mi2iMap_.end() &&

Evan Cheng wrote: > > On Dec 3, 2007, at 12:53 PM, Vladimir Prus wrote: > >> >> Suppose I have a target that does not have register+constant >> addressing mode. Then, I have DAG like: >> >> (store ..., (frameindex)) >> >> Targets like SPARC have the following patterns to catch this: >> >> def ADDRri : ComplexPattern<i32, 2,

Vladimir, I believe I've corrected this situation with version 1.299 of Makefile.rules. It now only uses find and install to do the installation of the header files. pax isn't used any more. Hopefully this helps you. Reid. On Wed, 2005-02-16 at 04:18, Vladimir Prus wrote: > Hello, > I've just tries make && make install on a fresh CVS tree, and get: > >

On Friday 15 April 2005 19:29, Chris Lattner wrote: > On Fri, 15 Apr 2005, Vladimir Prus wrote: > >> Another thing that might be interesting is the new llvm.pcmarker > >> intrinsic that Andrew recently added. I have no idea if it would be > >> useful to you or not, but... it's documented here: > >> http://llvm.cs.uiuc.edu/docs/LangRef.html#i_pcmarker

On Thu, 2004-07-01 at 09:26, Vladimir Prus wrote: > I've tried to implement the isMoveInstr method from TargetInstrInfo class, and > the register allocator immediately started to crash, in: > > #4 0x40e88787 in llvm::LiveIntervals::joinIntervals (this=0x80630b0) > at ../lib/CodeGen/LiveIntervals.cpp:493 > 493 assert(r2iA != r2iMap_.end()); >

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