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