Details
Diff Detail
Event Timeline
lib/Transforms/IPO/FunctionImport.cpp | ||
---|---|---|
597 | It will be more useful to name this something like thin_lto_src_module and attach the source module's name. |
lib/Transforms/IPO/FunctionImport.cpp | ||
---|---|---|
597 | I like the module name idea as well. We'd want to ensure that the module name MDString is uniqued though. | |
614 | Is the GV->GA name change in this block needed? Ah I see from the patch description that this was done for readability - can you make the renaming here and in the above loop a separate earlier NFC patch? |
lib/Transforms/IPO/FunctionImport.cpp | ||
---|---|---|
597 | tl;dr I don't think there is problem with that. do we really need to ensure that? In the worst case we will merge 2 the same nodes into one and we will not be able to distinguish one from another, but is there any way to make a unique name, that is readable to human? There are also 'distinct' nodes, but I am not sure if we should use that. | |
614 | What is NFC? Internet tells me "no fat chicks", but then my context analysis fails. |
lib/Transforms/IPO/FunctionImport.cpp | ||
---|---|---|
597 | I just meant that we don't want to have N copies of a full module name if we have N imports from that module. So hopefully it could be done in a way that each unique module name was an MDString and its metadata id would be referenced by the thin_lto_src_module metadata on the N imported functions. | |
614 | It means No Functional Change. Since it is a simple renaming that would apply and you don't need to submit a patch for review in phab. See other commits on the llvm-commits mailing list with "(NFC)" on the subject line for reference. |
lib/Transforms/IPO/FunctionImport.cpp | ||
---|---|---|
597 | oh yes, of course. |
Prefer "thinlto_src_module" (s/thin_lto/thinlto) for consistency with other ThinLTO references in llvm.
LGTM with that change.
It will be more useful to name this something like thin_lto_src_module and attach the source module's name.