[llvm-dev] Problem with local context getType() == global context getType()

John Criswell via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 26 10:51:48 PDT 2015


On 8/26/15 3:01 AM, koffie drinker wrote:
> Hi,
>
> Thanks for your reply. I did verify that all my calls are using the 
> correct *InContext api calls.
> I discovered that the types were in different context by testing with:
> 			auto t1 = LLVMInt1TypeInContext(context);
> 			auto t2 = LLVMInt1Type();
> The substituted value type in GVN.cpp equals to t2 instead of t1. So 
> It somehow is using a global context instead of my own during the GVN 
> pass. So I think it's a bug. It could be C api related.
> I willing to spend time on it and patch it if someone can point me to 
> the part where this might happen. I'm quite new to LLVM and unfamiliar 
> with the source tree.

I don't know where the C bindings are located in the source tree. 
However, if you think the GVN pass is causing the issue, its source code 
is in the lib/Transforms/Scalar/GVN.cpp file.

Regards,

John Criswell

> Regards
>
> On Wed, Aug 26, 2015 at 2:18 AM, John Criswell <jtcriswel at gmail.com 
> <mailto:jtcriswel at gmail.com>> wrote:
>
>     On 8/25/15 10:28 AM, koffie drinker via llvm-dev wrote:
>>     Hi,
>>
>>     I'm experiencing a weird problem with llvm 3.7(rc2/rc3) that did
>>     not occur in llvm 3.6.2
>>     I created a bug for it: https://llvm.org/bugs/show_bug.cgi?id=24521
>>
>>     I'm building a app where multiple code gen can happen in
>>     parallel. The documentation state that I need to use separate
>>     context. Each thread has it's own context.
>>
>>     When code generating a constant number I use the *InContext()
>>     calls to create the types. The assert fails since the optimizer
>>     replaces some numbers with a global type. The values are equal
>>     but the types are not. I did patch some calls to compare on
>>     getTypeID() but got another assert a couple of days later in
>>     another source file.
>
>     It sounds like the two values (or the types of the values) are in
>     different contexts.  If you are creating the Types, make sure each
>     type is created in the correct context.  If some LLVM API function
>     is creating the type for you, then it may be creating it in the
>     wrong context (i.e., you have found a bug) or the LLVM API
>     function has to assume a context (i.e., there is a limitation in
>     the API for your application).
>
>     If you determine that it is a bug, you should file a bug report. 
>     If it's a limitation, you should file an enhancement request.
>
>     Sorry I can't be more helpful than that; I haven't used LLVM 3.7
>     yet, and I haven't used multiple contexts within a multi-threaded
>     application.  These are educated guesses on my part.
>
>     Regards,
>
>     John Criswell
>
>>
>>     I needed 3.7 because of the LLVMAddGlobalMapping C api fixes.
>>     Could someone help me out ? Or point me in the right direction?
>>     I'm using the C api.
>>
>>
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>     -- 
>     John Criswell
>     Assistant Professor
>     Department of Computer Science, University of Rochester
>     http://www.cs.rochester.edu/u/criswell
>
>


-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150826/1ddea999/attachment.html>


More information about the llvm-dev mailing list