similar to: [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

On Mon, Jul 25, 2011 at 10:50 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> 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

Thanks for the response Chris, On Jul 26, 2011, at 0:44, Chris Lattner wrote: > > 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::

On Jul 26, 2011, at 4:03 AM, Garrison Venn wrote: >> Hi Garrison, >> >> Do the other two threads answer the question here? >> >> -Chris > > Yes I believe the other threads concerning the same issue answer why the system, because > of the lack of type linkage, is lenient in "unioning" types. What I'm still uncomfortable with is, I >

Hello, I'm updating a legacy code using LLVM 2.5 where it has an iteration through a Module's TypeSymbolTable to process each StructType. In LLVM 3.4, TypeSymbolTable has been removed. I can only find the LLVMContextImpl instance of a Module's LLVMContext which has AnonStructTypes and NamedStructTypes two maps. However, LLVMContextImpl is an opaque class which cannot be directly

I tried to compare two types. Because of renaming, the comparison result is not as expected. How to deal with renaming while comparing types? Best, Haopeng On 6/2/15 4:09 PM, Mehdi Amini wrote: > Hi Haopeng, > > One more element, I just noticed you are using LTO, I am not sure how it is implemented but my guess is that there is a shared LLVMContext. If multiple files include this

Hi Mehdi, Thanks for your reply. It seems caused by random rename because I saw %struct.StructTyName.692.475*, which might be twice renaming. Does this collision occur because this type is declared more than once? I encountered this problem when used clang to compile transmission 1.42 (http://download.transmissionbt.com/files/) with configuration: "./configure --disable-gtk". Then

Hi, LLVM community, I found an issue in my using scenario. We deliberately parse a bitcode file twice. It contains a named struct type. eg. %struct.cmd = type { float, float, float, float, float, i32 }. In the second module->dump, %struct.cmd becomes %struct.cmd0. my code is simplified like this. int main() { llvm::LLVMContext &llvmCtx = llvm::getGlobalContext(); string ErrMsg;

Hi All, I generated the following code with "clang -flto" command. void test(struct StruTyName *a) { ... } Then the type of test function is "void (%struct.StruTyName.100*)" by calling function::getFunctionType API. What's the meaning of number 100? Best, Haopeng

Hi, (sorry if the CC's are inappropriate, they seemed relevant based on a git log of IRMover.cpp) I'm using LLVM to implement Just-in-Time compilation for PostgreSQL. One part of that is doing inlining of operators. For that I'm using bitcode pre-generated using clang. The current code uses a single LLVMContext & Orc to generate the code. That largely workes well. But inlining

Hello, I'm updating a legacy code using LLVM 2.5 where it has an iteration through a Module's TypeSymbolTable to process each StructType. In LLVM 3.4, TypeSymbolTable has been removed. I can only find the LLVMContextImpl instance of a Module's LLVMContext which has AnonStructTypes and NamedStructTypes two maps. However, LLVMContextImpl is an opaque class which cannot be directly

> On Mar 23, 2018, at 16:11, Andres Freund via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > (sorry if the CC's are inappropriate, they seemed relevant based on a > git log of IRMover.cpp) > > I'm using LLVM to implement Just-in-Time compilation for PostgreSQL. One > part of that is doing inlining of operators. For that I'm using bitcode

Hi, On 2018-03-26 16:44:05 -0700, Duncan P. N. Exon Smith wrote: > > The second approach is to *not* cache modules but re-read them from disk > > (or memory, but that's irrelevant here). That works without any sort of > > asserts, but "leaks" memory because everytime a module is re-read from > > disk it re-creates types (cf

Hi all, We've run into a tricky situation in our work on the Crack compiler and I'm hoping that someone on this list can help us find the best solution. We're currently trying to implement "module caching" for Crack, similar to the feature in Python where module bitcode is persisted at compile time. When we import a module, before compiling the module we check for a

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

Hi all, I 'd like to fetch a list of structures, and found that it could be done via LLVMContextImpl *pImpl = Context.pImpl; pImpl->AnonStructTypes This however needs the inclusion of LLVMContextImpl.h, which is not contained in the includes dir, but in the lib/IR dir (next to the .cpp files) and is not installed under /usr/local/include... Whats the reason for this? Isn't it

On Jan 16, 2010, at 11:15 AM, Talin wrote: > OK here's the patch for real this time :) > > On Fri, Jan 15, 2010 at 4:36 PM, Talin <viridia at gmail.com> wrote: > Here's a work in progress of the union patch. Note that the test > "union.ll" does not work, so you probably don't want to check this > in as is. However, I'd be interested in any

Hi, I am trying to generate LLVM bytecode using CLANG and I ran into the following problem. If I run clang with the -emit-llvm option and then try to get a textual representation of the output using llvm-dis, the latter crashes because of a failed assertion in BitCodeReader.cpp, mentioning a "Type mismatch in value table" (the exact error message is appended at the end of this email).

Hi, For the first problem, try clang -S -emit-llvm test.c -o test.ll you should get the llvm IR and you don't need to use llvm-dis. Although I have tried your example with the exact commands and source code you posted and it worked just fine for me. I also use clang and LLVM 2.8 compiled from sources. For the second problem, suppress -emit-llvm, since you want the executable, not an object

Hello! I'm newer to LLVM development . I'm trying to use AllocaInst class to construct an instruction , I wrote like this: AllocaInst *alloc = new AllocaInst(llvm::Int32Ty, 0, "indexLoc",i); but it return the error: error: use of undeclared identifier 'llvm::Int32Ty' AllocaInst *alloc = new AllocaInst(Int32Ty, 0, "indexLoc",i); I