[llvm-dev] [ThinLTO] Using two different IRMovers for the same composite module? (related to PR28180)
Taewook Oh via llvm-dev
llvm-dev at lists.llvm.org
Fri Jul 22 14:34:16 PDT 2016
Yes, I have the repro, though I can’t publish it externally. It would be great if you can upstream the patch so I can try it. Thank you for your explanation as well!
From: <mehdi.amini at apple.com> on behalf of Mehdi Amini <mehdi.amini at apple.com>
Date: Friday, July 22, 2016 at 2:16 PM
To: Taewook Oh <twoh at fb.com>
Cc: via llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] [ThinLTO] Using two different IRMovers for the same composite module? (related to PR28180)
On Jul 22, 2016, at 1:50 PM, Taewook Oh via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
While trying ThinLTO, I ran into an assertion failure in IRMover: https://llvm.org/bugs/show_bug.cgi?id=28180<https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D28180&d=CwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=kOsLCgQzH7N8ptZ7diJD9g&m=YPo1XVjbxI5dqJXOdMZRPzHnL3CBAEk6IR74Edlb3Jg&s=C4gDkGqx2eaddJPKkXGtaZqrAn7mTi2w675GAwvY0G8&e=>.
Great, we encountered this bug last month and I have an fix internally but wasn’t sure how to reproduce (I didn’t have any source with internal bug report), so I haven’t upstream the patch yet.
Do you have the repro?
I found that the assertion failure is happening because IRMover tries to map the metadata that already mapped in the destination module, and it seems that this happens because two different IRMovers are used for the same destination (or composite) module.
It is not clear to me how using two different IRMovers is the issue: as you mentioned, the assertions is encountered when the metadata is already in the map, a new IRMovers would have a new fresh map.
My debugging of this issue lead me to the new "ODR type uniquing” feature in the context as the culprit. In this mode, when multiple modules are loaded in the context the composite type metadata are uniqued by id. It means that the same composite type (same as same pointer in memory) can be reached from two modules (here source and destination). So the mapper may reach a metadata in the source module and try to map it to the destination module while it is already there (but not in the map).
This happens only in ThinLTO and not in LTO because LTO starts with an empty module, so when you move the first module into the "merged module”, the map gets initialized. In ThinLTO the mover starts with the destination module not empty.
During LTO, an IRMover is created in thinLTOBackendTask function(tools/gold/gold-plugin.cpp). linkInModule function, which is called by thinLTOBackendTask, calls the ‘move’ function of this IRMover. The other IRMover is created when “TheLinker” is created in FunctionImporter::importFunctions (lib/Transforms/IPO/FunctionImport.cpp). thinLTOBackendTask invokes FunctionImporeter::importFunctions as well, with a call chain of thinLTOBackendTask -->CodeGen::runAll (tools/gold/gold-plugin.cpp) --> CodeGen::runLTOPasses ((tools/gold/gold-plugin.cpp)--> FunctionImporter::importFunctions.
As these two IRMovers share the same destination module, when the second IRMover tries to map the metadata already mapped by the first IRMover, it eventually results the assertion failure. It seems that IRMover maintains SharedMDs to keep the metadata mapping record across the multiple calls of its move function, but that doesn’t help between two separate IRMovers.
What would be the right fix for this? Please let me know if I misunderstand something.
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev