Hi again,
it turned out that the problem still persisted, when I ran the code on
an ARM platform which I finally have to use for my thesis.
After compiling LLVM and pocl over and over again in different
compositions and hacking around in both sources, I finally gave up.
I now worked around the issue by putting my analysis part in a separate
executable and using interprocess communication. Not a very nice
solution, but this way the LLVM instances of pocl and my part don't
collide anymore.
Regards
Gunnar
Am 19.11.2015 um 11:19 schrieb Pekka Jääskeläinen:
> Hi,
>
> This is the old problem with LLVM's command line argument
> implementation that brings this type of issues every now
> and then.
>
> In your case it was probably due to dynamically loading the
> LLVM again to the process which then autoregisters the cmdline
> option and failed. I'm not sure why it disappeared when
> linking LLVM statically to libpocl.so though.
>
> But good that it works,
> Pekka
>
> On 11/19/2015 11:47 AM, Gunnar Wüllrich wrote:
>> Hello again,
>>
>> I now compiled pocl with --enable-static-llvm.
>> Probably an ugly workaround, but this seems to solve my issue for now.
>>
>> Regards
>> Gunnar
>>
>> Am 18.11.2015 um 18:05 schrieb Gunnar Wüllrich:
>>> Hi,
>>>
>>> for my master thesis I attempt to implement a custom ICD loader that
>>> only exposes a pseudo device to the outside and then dispatches OpenCL
>>> calls itself to the real devices. Until now, the base system worked
>>> quite well so far, with pocl as a runtime.
>>>
>>> Now I attempt to use Clang/LLVM to do some analysis on the OpenCL code
>>> that I can finally use to decide where exactly to run the kernels.
>>> However, I can't get pocl and this analyser work together.
>>> If pocl did not yet create its cache, the applications segfaults on
>>> calls to clEnqueueNDRangeKernel with the additional message:
>>> Two passes with the same argument (<these vary>) attempted to be
>>> registered!
>>>
>>> In my first attempt I used the default global LLVM context and figured
>>> that this might somehow interfere with the pocl context.
>>> Therefore I created a new LLVMContext, but to no avail. This alone also
>>> seems to break something, as little as calling:
>>>
>>> void analyse(..) {
>>> llvm::LLVMContext* myContext = new llvm::LLVMContext();
>>> delete(myContext);
>>> }
>>> leads to the same error described above.
>>> In both cases though, the program does not crash, if the pocl cache was
>>> created beforehand.
>>>
>>> Do you have an idea how I can employ LLVM functionality without
>>> interfering with pocl's operation? I am not at all familiar with LLVMs
>>> inner workings, so I might be missing something obvious.
>>>
>>> Best regards
>>> Gunnar Wüllrich
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> pocl-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/pocl-devel
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> pocl-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/pocl-devel
>>
------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
pocl-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pocl-devel
