[llvm-bugs] [Bug 44337] IR with double constant doesn't work with OrcJIT build by MSVC

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Jan 22 15:01:19 PST 2020


https://bugs.llvm.org/show_bug.cgi?id=44337

Lang Hames <lhames at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #24 from Lang Hames <lhames at gmail.com> ---
> I have ported your patch from #40074 to LLVM 9.0.0 and tested it in the mine environment.
> Your patch is working fine for me.
> Also, it fixes bug #44336.

That's great news. :)
Ok -- closing this as fixed by 84217ad6611.

> But are you sure that it is a good idea to pass a parameter by value?
> Error defineMaterializing(SymbolFlagsMap SymbolFlags);
> If you don't want to modify the map, a constant reference is a better solution, if you want to modify, a non-constant reference or pointer is more applicable here, in my opinion.

The JITDylib::defineMaterializing method makes modifications to the map based
on what definitions are accepted and rejected, and returns these to
MaterializationResponsibilty::defineMaterializing so that it can update the
responsibility set. Since these modifications are not interesting to the
client, it makes sense to pass by value: It is cheap, and if the client does
not need their value any more then no copies are required.

> One more question for you: is removing a module from OrcJIT will be available in LLVM 10?

Unfortunately support for removing modules will not make it in to LLVM 10. The
best solution for now is to maintain a separate ExecutionSession for code that
you want to throw away. I am working on removable module support, and hope to
get it in to LLVM 11.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200122/2a3f7e43/attachment.html>


More information about the llvm-bugs mailing list