llvm dev - Aug 2015 - Problem with local context getType() == global context getType()

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150825/02ab74c3/attachment.html>

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
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150825/1147bd72/attachment.html>

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.


Regards



On Wed, Aug 26, 2015 at 2:18 AM, John Criswell <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 listllvm-dev at
lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> --
> John Criswell
> Assistant Professor
> Department of Computer Science, University of
Rochesterhttp://www.cs.rochester.edu/u/criswell
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150826/76dc7563/attachment.html>