similar to: [LLVMdev] "pure" functions"

On Sun, 4 Jun 2006, Vladimir Prus wrote: > say I've a LLVM module with a call instruction. The called function is > "pure", that is it has no side-effects at all. How can I communicate this > to LLVM, so that the function call can be removed if the return value is > never used? There isn't a way to do this from the source code yet. However, if this is a standard

On Sun, 2006-06-04 at 11:49 -0500, Chris Lattner wrote: > On Sun, 4 Jun 2006, Vladimir Prus wrote: > > say I've a LLVM module with a call instruction. The called function is > > "pure", that is it has no side-effects at all. How can I communicate this > > to LLVM, so that the function call can be removed if the return value is > > never used? > >

Hello, I've just tries make && make install on a fresh CVS tree, and get: llvm[0]: Installing include files /bin/sh: line 1: pax: command not found Two questions. 1. Why install process requires some nonstandard tool? Is it possible to get away without it. 2. autoconf/configure.ac has this: AC_PATH_PROG(PAX, [pax], [pax]) but Makefile.rules uses plain 'pax',

Hi, everytime one has to add instruction at the beginning of a basic block, one has to skip past PHI nodes that are already there. How about adding a new method to BasicBlock, to get that first non-PHI instruction? So, adding an instruction will be as simple as: new SomeInstruction(............., BB->getFirstNonPHI()) Patch attached. Comments? - Volodya -------------- next part

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

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

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

Hello, I'm playing with alias analysis, using the following program: %i = external global int ; <int*> [#uses=2] implementation ; Functions: int %_Z3bari(int %p) { entry: %tmp.0 = load int* %i ; <int> [#uses=1] %tmp.1 = setgt int %tmp.0, 10 ; <bool> [#uses=1] br bool %tmp.1, label %then, label %UnifiedReturnBlock then:

I've another problem. There's one register, gr6, which is used to return high part of return value for functions returning 64-bit values. For such functions, the register should not be saved, naturally. But when function does not return 64-bit value, then the register must be saved. How can I express this in .td file? - Volodya

Hello, after some time I'm trying to build my code with the current CVS of LLVM, and have a problem. The mentioned file, around line 184, contains: if (FixedSlot == FixedSpillSlots+NumFixedSpillSlots) { // Nope, just spill it anywhere convenient. FrameIdx = FFI->CreateStackObject(RegInfo->getSpillSize(Reg)/8,

On my target, the multiplication can involve all general purpose registers, but there's are still some restrictions: the first and the second operand as well as the result must be in different registers, and neither register can be gr7. How can I enforce this restriction on the register allocator? - Volodya

Hi, 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 duplication. If desired, SelectionDAGISel can have both

Hi Reid, > Instructions are members of a linked list. Consequently if you insert > some Instruction, that instruction gets changed. So, its not const. > > Simple enough? Yes, thank you. I started thinking if "mutable" is right here, but that's long philosophical issue ;-) - Volodya

I've finally managed to bring my backend to a minimally working form. I can compile three small examples with arithmetic operations, branches and phi operations. However, there surely is a lot of omissions and bugs. How do I test a backend. For obvious reasons, I'd prefer a number of really small tests, to make debugging easier. I see some number of such small tests in

Reid Spencer wrote: > Volodya, > > I think you may need to update your CFE and rebuild. I compiled the test > using my local build and I didn't get the results you see below. I'm > also very surprised to see this output. The first %tmp.11 should have > been %tmp.1 .. not sure how it got corrupted. In any event, the > attachment is obviously generated by code that runs

On Monday 25 April 2005 14:43, Vladimir Prus wrote: > The 'i' variable is never modified in the program, however, all analyses > except for -globalsmodref-aa report that the > > %tmp.3 = call int %_Z3bari( int %p ) ; <int> [#uses=1] > > instruction can modify 'i'. I'm somewhat surprised, because it looks like > -globalsmodref-aa is the simplest

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() && "Invalid instruction!"); return it->second; } The crash happens

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 them all to stack -- even if > > they are not modified at all. > > >

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 underfined". Forget this, I've missed the 'LL'

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