[PATCH] D143229: [FunctionImporter] Don't upgrade debug info if llvm.idents match

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 6 08:42:12 PST 2023


dblaikie added a comment.

In D143229#4101609 <https://reviews.llvm.org/D143229#4101609>, @mehdi_amini wrote:

> In D143229#4101291 <https://reviews.llvm.org/D143229#4101291>, @dblaikie wrote:
>
>> In D143229#4101256 <https://reviews.llvm.org/D143229#4101256>, @mehdi_amini wrote:
>>
>>> A flag seems a bit ad-hoc to me, can we detect from the bitcode itself if this is necessary?
>>
>> Not really that I know of - if it's untrusted bitcode, everything's got to be validated/can't just check a version flag and assume it's good.
>
> The description in this revision isn't about "trust" but about "matching revision", can you elaborate what you have in mind as "trust" issue here?

In the sense that if I write some handcrafted IR, LLVM should verify it before moving forward because other things interacting with the IR will assume it's valid & may crash if it isn't. So there's a trust boundary, generally - like in memory IR usually isn't verified, it's assumed the producer produced something valid by construction & it's a bug on the producer side if it didn't. But generally once we're reading things off disk we assume it might have come from anywhere & to be somewhat stable/not so crashy, we usually verify it on input (at least that was/is my rough understanding). So if you happen to be willing to sacrifice that extra stability guarantee because because you can guarantee that outside the system outside the program will ensure that only valid IR is passed in - then maybe having a flag to communicate that guarantee would be appropriate.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143229/new/

https://reviews.llvm.org/D143229



More information about the llvm-commits mailing list