Displaying 20 results from an estimated 500 matches similar to: "[LLVMdev] Getting A Type By Name"
2004 May 11
3
[LLVMdev] ExecutionEngine/Interpreter/ExternalFunctions.cpp
Hi,
I'm working on bug 122, consolidating the interface to the SymbolTable
class. In doing so, I found the function below which traverses the
symbol table but apparently unnecessarily. Before I remove the
traversal, I thought I better check with you guys. Posted this to the
list because it looks like _everyone_ has edited this file :)
In the code below, the IOB variable is the only thing in
2004 May 11
0
[LLVMdev] ExecutionEngine/Interpreter/ExternalFunctions.cpp
I mis-stated what I think should be deleted.
The block of code from "GlobalVariable *IOB = 0;" to the end of the loop
should be delted because the only effect the loop has is on the IOB
variable and that variable is never used after the loop.
Reid.
On Tue, 2004-05-11 at 18:14, Reid Spencer wrote:
> Hi,
>
> I'm working on bug 122, consolidating the interface to the
2004 May 11
1
[LLVMdev] ExecutionEngine/Interpreter/ExternalFunctions.cpp
And, one more weird thing in this function. The FILESize static variable
is never initialized so its likely initial value is 0 due to zero fill
on many MMUs. The value is never written and used as a divisor. Why
hasn't this function caused an arithmetic violation? Because the IOBBase
point, also a static variable is initialized to zero and never modified
and used in a conditional that thwarts
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
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
2004 May 25
1
[LLVMdev] ATTENTION: SymbolTable Change!!
LLVMers,
On the way to resolving bug 122, I am committing my SymbolTable rewrite.
If you are working on anything that uses the SymbolTable, I suggest you
read the documentation in include/llvm/SymbolTable.h.
The changes I've committed reduce the use of Type::TypeTy. This static
member will go away in the future, so please do not propagate new code
that uses it. There is no reason to use it
2010 Jul 22
2
[LLVMdev] Casting.h illness
On Jul 22, 2010, at 10:57 AM, Gabor Greif wrote:
> Am 22.07.2010 um 00:21 schrieb Chris Lattner:
>
>> On Jul 21, 2010, at 12:49 PM, Eugene Toder wrote:
>>> Is this a recommended approach/good style/good idea to use
>>> dyn_cast_or_null<X>(I) instead of dyn_cast_or_null<X>(*I)? (And other
>>> is and cast functions).
>>
>> We
2018 Jul 25
2
are the LLD libraries thread safe?
E.g. Is it intended to be allowed to call lld::elf::link in 2 different
threads at the same time?
Follows is an example Valgrind error I ran into when doing the above.
I'll try putting a global resource lock on invoking LLD and see if it
solves the problem.
==5467== Invalid write of size 8
==5467== at 0x525509:
llvm::DenseMapBase<llvm::DenseMap<llvm::CachedHashStringRef, int,
2018 Jul 25
2
are the LLD libraries thread safe?
Hi Andrew,
LLD relies on various bits of global state which are manipulated during the
link, so I wouldn't expect it to be thread safe at that level, although it
does attempt to reset that global state at the start of each call to
link(), so it should be callable sequentially.
Regards,
James
On 25 July 2018 at 02:37, Andrew Kelley via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
2020 May 18
2
Understanding LLD's SymbolTable's use of CachedHashStringRef
I was looking at the SymbolTable code in LLD COFF and ELF recently, and I’m confused by the use of CachedHashStringRef.
From what I understand, a CachedHashStringRef combines a StringRef with a computed hash. There’s no caching going on in the CachedHashStringRef itself; that is, if you construct CachedHashStringRef("foo"), and then construct a second
2004 Jan 07
1
[LLVMdev] Finding Things In SymbolTable
The SymbolTable is a map of Type* to a map of names to Value*. This
means that in order to lookup something by name you first have to know
what type it is. For the basic types this is fine because you generally
always know which basic type you're after. But, for derived types, this
can be quite complicated. It isn't always possible to know the exact
type.
In XPL, types are just names.
2010 Jul 22
0
[LLVMdev] Casting.h illness
Am 22.07.2010 um 23:29 schrieb Chris Lattner:
>
> On Jul 22, 2010, at 10:57 AM, Gabor Greif wrote:
>
>> Am 22.07.2010 um 00:21 schrieb Chris Lattner:
>>
>>> On Jul 21, 2010, at 12:49 PM, Eugene Toder wrote:
>>>> Is this a recommended approach/good style/good idea to use
>>>> dyn_cast_or_null<X>(I) instead of
2011 Apr 07
1
[LLVMdev] description of llvm::cast correct?
Hi!
in the description of llvm::cast it says:
But it will correctly return NULL when the input is NULL.
And in the description of llvm::cast_or_null it says:
Functionally identical to cast, except that a null value is accepted
This sounds to me as if both functions accept a null pointer.
What is then the difference between cast and cast_or_null?
-Jochen
2011 Oct 16
2
[LLVMdev] Static destructor problem with recent HEAD
On Sat, Oct 15, 2011 at 9:49 PM, Chandler Carruth <chandlerc at google.com>wrote:
> On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote:
>
>> I recently updated my version of LLVM from revision 140108 to 142082, and
>> several things broke, most of which were easily fixed. However, I'm now
>> getting a "pure virtual method called"
2011 Jul 09
1
[LLVMdev] getting and setting array indices c interface
I really can't figure out how to get and set array indices from the c
interface.
so to get an element I'm calling
tindex = *fn\SymbolTable(*index\name)
index = LLVMBuildLoad(builder,tindex,"index")
arr = *fn\SymbolTable(*array\name)
arrptr = LLVMBuildLoad(Builder,arr,"arrayptr")
tmp = LLVMBuildGEP(Builder,arrptr,index,0,"ptr")
ptr =
2003 Nov 17
3
[LLVMdev] Question about structure of SymbolTable
I was trying to look through the SymbolTable code for LLVM. What does
the SymbolTable for a Module contain? Is it just GlobalVariables and
Functions? How are program constants and static variables declared
within functions handled? When I said program constants, I meant
things like strings (e.g., char* foo = "Hello world\n";). Thanks in
advance.
Sincerely,
Brian
Brian M.
2011 Oct 16
0
[LLVMdev] Static destructor problem with recent HEAD
On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote:
> I recently updated my version of LLVM from revision 140108 to 142082, and
> several things broke, most of which were easily fixed. However, I'm now
> getting a "pure virtual method called" exception (__cxa_pure_virtual) which
> I wasn't getting before. This is happening in the destructor of
2011 Oct 16
0
[LLVMdev] Static destructor problem with recent HEAD
Interestingly, I also get a similar error in a different executable (my
unittest):
pure virtual method called
terminate called without an active exception
0 tartc 0x00000001010a8265 PrintStackTrace(void*) + 53
1 tartc 0x00000001010a88cc SignalHandler(int) + 364
2 libSystem.B.dylib 0x00007fff831341ba _sigtramp + 26
3 libSystem.B.dylib 0x7261742e65637365 _sigtramp +
2011 Oct 16
2
[LLVMdev] Static destructor problem with recent HEAD
I recently updated my version of LLVM from revision 140108 to 142082, and
several things broke, most of which were easily fixed. However, I'm now
getting a "pure virtual method called" exception (__cxa_pure_virtual) which
I wasn't getting before. This is happening in the destructor of a
statically-initialized object. (More precisely, it's blowing up in a
BumpPtrAllocator,