similar to: [LLVMdev] Re: [llvm-commits] CAUTION: Type != Value

Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] Re: [llvm-commits] CAUTION: Type != Value"

2004 Jul 10
0
[LLVMdev] Re: [llvm-commits] CAUTION: Type != Value
Vladimir, As you noted, the cast to Value* from (I presume) Type* is now invalid as there is no inheritance relationship. You can give a type a name by converting: Ty->setName(Name, &ST) to: ST.insert(Name, Ty) Hope that helps. Reid. On Sat, 2004-07-10 at 07:01, Vladimir Merzliakov wrote: > In VMCore/Module.cpp i found line (254): > > ((Value*)Ty)->setName(Name,
2005 Mar 21
0
[LLVMdev] Recursive Types using the llvm support library
On Sun, Mar 20, 2005 at 07:01:55PM -0600, Chris Lattner wrote: > On Sun, 20 Mar 2005, John Carrino wrote: > > >On Wed, Mar 09, 2005 at 04:05:32PM +0300, Vladimir Merzliakov wrote: > >>>>Is assert(!NewSTy->isAbstract()) must pass after this line? > >>> > >>>In this case, yup. > >>> > >>I create test program and assert
2005 Mar 21
1
[LLVMdev] Recursive Types using the llvm support library
On Sun, 20 Mar 2005, John Carrino wrote: >> In practice, this is leads to a horrible mess, as you've noticed. As >> such, I'd suggest using Module::addTypeName to give these things names so >> that you have a hope to understand them and so they are more compact :) > > I took your advide and used Module::addTypeName which is a great idea > that I didn't know
2004 Jul 10
1
[LLVMdev] Re: [llvm-commits] CAUTION: Type != Value
> As you noted, the cast to Value* from (I presume) Type* is now invalid > as there is no inheritance relationship. You can give a type a name by > converting: > > Ty->setName(Name, &ST) > > to: > > ST.insert(Name, Ty) > > Hope that helps. This is resolve problem for me. Is attached patch ok for llvm/lib/VMCore/Module.cpp ? Vladimir --------------
2005 Mar 21
2
[LLVMdev] Recursive Types using the llvm support library
On Sun, 20 Mar 2005, John Carrino wrote: > On Wed, Mar 09, 2005 at 04:05:32PM +0300, Vladimir Merzliakov wrote: >>>> Is assert(!NewSTy->isAbstract()) must pass after this line? >>> >>> In this case, yup. >>> >> I create test program and assert failed in it: >> >> { \2 *, sbyte * } > > How do I decode the \2 in this? I am
2005 Mar 26
2
Is there a diferent way to do this?
Hi, I started creating a small class but I'm courious about how it is working. To create a instance of my class "Partri" I write this at Rgui: x <- new("Partri", name="Gilvan") and to change the slot "name" of this instance, I write: setName(x, newname="Justino") It is not working, because when I type "x" at Rgui, it shows
2006 Apr 27
3
HELP!!!! What is the CGIXXXX.YYY stored in /tmp/ ?????
Hi, We have a website which loads a data file and then create a html file (according to the data file) with more than thousand of combobox at a time (on the same page). The first time we load that page, everything seems fine. all combobox have been created. But when we load a second data file (not the same) the system seems to create some tempoary files which contains the first choice of the
2011 Sep 15
1
[LLVMdev] problems naming a function
I created a new Function in code(for a pass), and now I want to name it to make the IR more readable. Function inherits GlobalValue, which eventually inherits Value. Value has the setName() method. When I do this on my new function(newFunc->setName(string("testing"))) I get back "error: ‘setName’ was not declared in this scope". What is the correct way todo this? Thanks
2016 Mar 14
4
LLVM 3.8 change in function argument lists?
Hi, I am upgrading my project from 3.7 to 3.8. I find that following code used to compile in 3.7 but doesn't in 3.8 and I can't understand why. llvm::Function *mainFunc = ...; auto argiter = mainFunc->arg_begin(); llvm::Value *arg1 = argiter++; arg1->setName("obj"); But if I change the code to following it compiles: auto argiter = mainFunc->arg_begin(); llvm::Value
2011 Nov 17
2
[LLVMdev] Fwd: Problem getting LoopInfo inside non-LoopPass
Nick, Thanks for this info, though this didn't help my problem at all. On Wed, Nov 16, 2011 at 7:21 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Never create a Twine as a local variable. > > V->setName(Twine("new_name")); > > should work fine, however. Note that Twine itself has an implicit > constructor from const char *, so this code: > >
2011 Jul 25
4
[LLVMdev] Lack of use of LLVMContextImpl::NamedStructTypes
Several people on this list have reported issues with the linker regarding a named StructType instance with the same name in two different modules being resolved into two StructTypes with different names due to StructType:: setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…), I don't see use of LLVMContextImpl::NamedStructTypes or of Module::getTypeByName(…). Nor do
2008 Apr 16
2
[LLVMdev] Problems in removing a cloned instruction.
Hi all, I am trying to write a pass where i am creating a clone of a function (the only difference being, the new function returns void , instead of any value). I am creating a new Function Type with a void return type (rest being the same as original function), and using this i am creating a new function body. Then, i clone the body of the old function into new function, but when ever i
2008 Apr 16
0
[LLVMdev] Problems in removing a cloned instruction.
Hi, I'm gonna try to give some feedback, but I have only been working with LLVM for a few days, so don't take what I'm saying without verifying :-) > BasicBlock *ProgSlicer::CloneBasicBlock(const BasicBlock *BB, > DenseMap<const Value*, Value*> &ValueMap, > const char *NameSuffix, Function *F) { > > BasicBlock
2018 Mar 23
3
Change function call name in a CallInst only in certain functions
Hello, In my module I have functions: a b c f3 calls "a" f2 calls "a" f1 calls "b" I would like to modify a CallInst in the f2. Now it calls "a", but I want changed it to "c". When loop over the instructions of the f2, I can get a CallInst to be modified, then I use "setName" to changed it to "c". Problem is, since
2011 Nov 17
0
[LLVMdev] Fwd: Problem getting LoopInfo inside non-LoopPass
Never create a Twine as a local variable. V->setName(Twine("new_name")); should work fine, however. Note that Twine itself has an implicit constructor from const char *, so this code: V->setName("new_name"); should also work fine. Nick Ryan Taylor wrote: > Basically I have two separate passes (first is a loop pass) which are > two different files and
2018 Mar 24
0
Change function call name in a CallInst only in certain functions
You are probably calling setName() on the called Function, which in-turned renamed the called Function instead of replacing the called function. Depending on your use-case, if you are certain that you only need to modify CallInsts, then you could simply call CallInst::setCalledFunction , otherwise it’s probably wiser to use CallSite as a wrapper for both CallInst and InvokeInst. Do note, however,
2011 Nov 17
0
[LLVMdev] Fwd: Problem getting LoopInfo inside non-LoopPass
So is this simply not possible? On Thu, Nov 17, 2011 at 10:31 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Nick, > > Thanks for this info, though this didn't help my problem at all. > > > On Wed, Nov 16, 2011 at 7:21 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > >> Never create a Twine as a local variable. >> >>
2011 Nov 17
2
[LLVMdev] Fwd: Problem getting LoopInfo inside non-LoopPass
Basically I have two separate passes (first is a loop pass) which are two different files and two different opts but I need to keep the data consistent (ie, I want the changes to show up the resulting .bc output file from the first (loop) pass so the second pass can use these new names. Currently, when I print out "BB->getName().str()" after the code below, I get the correct renaming
2011 Jul 19
1
[LLVMdev] StructType::setName(...)
My apologies if this has already been discussed/explained (reference?). In browsing the new type system implementation, I was wondering if someone could give a simple example of why one would want to reset the name of a previous realized StructType instance (setBody(...) has been called). My curiosity is enhanced by the fact that reseting a name of a StructType instance may result in a symbol
2011 Jul 26
0
[LLVMdev] Lack of use of LLVMContextImpl::NamedStructTypes
On Jul 25, 2011, at 10:50 AM, Garrison Venn wrote: > Several people on this list have reported issues with the linker regarding a > named StructType instance with the same name in two different modules > being resolved into two StructTypes with different names due to StructType:: > setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…), > I don't see