[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