similar to: [LLVMdev] Tracking global variables accesses

On Wednesday 20 April 2005 17:41, Chris Lattner wrote: > On Wed, 20 Apr 2005, Vladimir Prus wrote: > > Is there any analysis in LLVM that can be used to obtain, for a function, > > the list of all global variables that may be modified as a result of a > > call to that function (taking into account any calls in those function > > and aliasing). If not, what's the best

On Wed, 20 Apr 2005, Vladimir Prus wrote: > Is there any analysis in LLVM that can be used to obtain, for a function, the > list of all global variables that may be modified as a result of a call to > that function (taking into account any calls in those function and aliasing). > If not, what's the best way to implement such a analysis? No, not directly. However, with the

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:

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

On Mon, 25 Apr 2005, Vladimir Prus wrote: > The GlobalsModRef::getModRefInfo has this logic: > > // If we are asking for mod/ref info of a direct call with a pointer to a > // global we are tracking, return information if we have it. > if (GlobalValue *GV = const_cast<GlobalValue*>(getUnderlyingObject(P))) > if (GV->hasInternalLinkage()) > > So, no

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

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

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

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

Chris Lattner wrote: > > Right, but you'd need HTTP/FTP server. Not a problem for *me*, but lots > > of folks are behind firewalls and can't do that. > > Sure. I can't imagine that there is a wonderful solution other than this > though. In particular, how can you do distributed development without it? > The whole idea is to reduce the need for a completely

On Monday 25 April 2005 23:40, Chris Lattner wrote: > On Mon, 25 Apr 2005, Vladimir Prus wrote: > > The GlobalsModRef::getModRefInfo has this logic: > > > > // If we are asking for mod/ref info of a direct call with a pointer > > to a // global we are tracking, return information if we have it. > > if (GlobalValue *GV = > >

I've just had some fun, because I wanted to override FunctionPass::addAnalysisUsage, but forgot "const" after the method name -- so instead of overriding I've just created a new unrelated method. After spending some time on this, I've decided to add -Woverloaded-virtual option to compiler to catch such cases. However, it also gives some warnings on LLVM code:

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

On Thursday 22 September 2005 19:12, Chris Lattner wrote: > On Thu, 22 Sep 2005, Tzu-Chien Chiu wrote: > > On 22/09/05, Bill Wendling <isanbard at gmail.com> wrote: > >> Couldn't you state the explicit namespaces. So not using "using > >> namespace llvm" and instead prefix all calls with "llvm::"? > > > > The header files in

Hi, 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? Thanks, 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