similar to: [LLVMdev] GenRegisterInfo.h.inc

On Tue, 12 Oct 2004, Paolo Invernizzi wrote: > Hi all, > I cannot figure out why is named GenRegisterInfo.h.inc and not > GenRegisterInfo.inc ... > Is it for a dependency problem? I'm not sure what you're saying here. In the X86 backend, for example, we generate both X86GenRegisterInfo.h.inc and X86GenRegisterInfo.inc. The former is #included into X86RegisterInfo.h and the

In r155270, I removed code from TableGen that emitted XXXRegisterClass into GenRegisterInfo.inc. This value was just a const pointer to XXXRegClass. So all places that used XXXRegisterClass should be changed to &XXXRegisterClass. I already did the conversion for all targets in the tree so this is a notice to out of tree targets. One of the most common place you might find this is setting up

On Tuesday 16 May 2006 03:19, Chris Lattner wrote: > On Mon, 15 May 2006, Nai Xia wrote: > > > In other words, if I only use -steens-aa and the data_XXXs are all > > external global variables( and so inComplete ), > > Sounds right! > > > the call to printf will > > make the same effect, which I have tested it. > > > > Am I right ? :) >

Reid, After your recent redefinition of arg_iterator, it's missing increment/decrement operators (which people typically expect to be defined for iterators). So some external code relying on this is broken. If it's not intentional, would be nice to have it fixed. Specific code that I is broken looks like this: llvm::Function f; foo(--f->arg_end()); // passing the last argument to the

> The predecrement / decrement operators *do* exist on this iterator: > https://github.com/llvm-mirror/llvm/blob/master/include/ > llvm/ADT/ilist_iterator.h#L153 > > Maybe you meant: > > llvm::Function *f; > foo(&*--f->arg_end()); > > ? > Correct, I mean exactly this. Though &* is not important in this case. This code doesn't work anymore, as

Hi everyone, I found some peculiar behavior of TableGen when generating [TARGET]GenRegisterInfo.inc. Some register overlaps are generated twice in this file, leading to a compilation error. I think this is because in RegisterInfoEmitter.cpp, RegisterAliases are declared as "std::map<Record*, std::set<Record*>, LessRecord>" and a requirement for std::map is that the

On Wed, 17 May 2006, Nai Xia wrote: > Unfortunately, I did not locate the lines in steens-aa for "printf" special case. > In ds-aa, I found the lines below: Right, steens-aa and ds-aa share code for "local analysis", they just stitch it together into an interprocedural analysis in different ways. The code below is used for steens-aa. >

On Mon, 15 May 2006, Nai Xia wrote: > In other words, if I only use -steens-aa and the data_XXXs are all > external global variables( and so inComplete ), Sounds right! > the call to printf will > make the same effect, which I have tested it. > > Am I right ? :) If you've tested it then, yes you're right :). I haven't played with this stuff for a long time,

On Tue, Sep 6, 2011 at 9:34 PM, Alexandru Dura <alexdura at gmail.com> wrote: > Hi everyone, > > I found some peculiar behavior of TableGen when generating > [TARGET]GenRegisterInfo.inc. Some register overlaps are generated twice in > this file, leading to a compilation error. Hi, What do you mean "overlapped register"? > I think this is because in

On 9/17/2015 7:04 AM, Sky Flyer via llvm-dev wrote: > It seems like d0 is always 14! > I check it with ARMGenAsmMatcher.inc it was the same! > How is it possible? because it should give the same register value that > matches the underlying platform not any autogenerated value!? The returned number is the register id as defined in <YourTarget>GenRegisterInfo.inc. These numbers

Hi Chris, I took a haste look at the "Points-to Analysis in Almost Linear Time" by Steens , your PHD thesis and SteensGaard.cpp in LLVM this afternoon. So I think: 1. Actually the basic algorithm described originally by SteensGaard does not provide MOD/REF information for functions. 2. The context insensitive part of Data Structure Analysis (LocalAnalysis) can be deemed as an

Hello, Thanks to recent changes in the SVN, I was able to successfully build LLVM under Windows in the following environments: 1. Cygwin; 2. MinGW/MSYS; 3. "gcc -mno-cygwin" (a.k.a MinGW on Cygwin). For 3., I've had to make a few manual changes to the build system. Care is needed because non-Cygwin external commands require Windows paths and Cygwin's make does not like path

Joel Peshkin wrote: > > I hacked in the following additonal changes... > > Index: newhidups.c > =================================================================== > RCS file: /cvsroot/nut/nut/drivers/newhidups.c,v > retrieving revision 1.1.1.1.8.6.2.21 > diff -u -r1.1.1.1.8.6.2.21 newhidups.c > --- newhidups.c 7 Nov 2005 22:14:20 -0000 1.1.1.1.8.6.2.21 > +++

Folks, So, I think we kind of agree that some named registers could be implemented, and that it should be an intrinsic that passes the name of the register down. This C code: register unsigned long current_stack_pointer asm("sp"); unsigned long get_stack_pointer_addr() { return current_stack_pointer; } void set_stack_pointer_addr(unsigned long addr) { current_stack_pointer = addr;

Hi all, Sorry for the inconvenient about the previous post. The files were not attached. So I put them here again. I am a newbie in LLVM and I am trying to replace the function like: old function || new function ============================== ========= int haha(int a) { int haha(int a, char* ID) { ===> }

Hi, all I am trying to write a function pass to replace a old function to a new function like: int haha(int a) { } ==> int haha(int a, char *IO) { } The below is a part of my code and generate segmentation fault. Can you help me to fix it? Thanks, Shawn // Since we have now created the new function, splice the body of the old // function right into the new function, leaving the

Hi, I'm trying to add function calls in the LLVM IR using the IRBuilder class. I've read both tutorials about functions but I still get assertion errors. I allocate memory for all function arguments and pass them as explained in the tutorial. My code is (this function is supposed to add a call to f in bb at pos): void addCallSite(Function *f, BasicBlock *bb, BasicBlock::iterator pos)

I'm now writing a pass and I wanna ask a question about how to duplicate the function and add duplicated arguments in llvm, for example: func(int a, char *b) -> func(int a, char *b, int a1, char *b1) I'm now stuck at using "getOrInsertFunction" and how to handle "getArgumentList", please share your opinion, thanks a lot! James

On Tue, 10 Oct 2006, Roman Levenstein wrote: >>> such a call instruction? >> >> Why not just make the asm string be "call __fsub64"? > > Well, of course it would be the best solution. But the interesting part > is that I need to generate the machine code directly because for > different reasons use of a system assembler is not an option. As a ok. >

Dear LLVMers, Here is the current, tentative schedule for LLVM 1.5: 1. We are hoping to have all relevant features and bug fixes into mainline CVS by Friday of this week. For those of you with commit access, please plan to have all of your changes for LLVM 1.5 committed by 9 am (CST) this Friday. If you need more time, please email the list. 2. On Friday, I will be making the 1.5 release