[PATCH] D112349: [Verifier] Add verification logic for GlobalIFuncs

Erich Keane via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 5 05:58:58 PDT 2021


erichkeane added a comment.

In D112349#3109994 <https://reviews.llvm.org/D112349#3109994>, @ibookstein wrote:

> I see. What is the guiding principle there, though? Generating correct IR "up front" / "the first time" rather than "fixing it up as you go via manipulations"? (could you give a link?)
> I can see the engineering consideration in not letting IR manipulations creep into the CFE, I just want to make sure that's the principle that we're asked to follow.
> In the end this isn't the first instance where the "streaming" design of GlobalDecl emission forces a fixup/rewrite of a previous decision, as can be evidenced by a close sibling of this feature, `CodeGenModule::EmitAliasDefinition` (which uses exactly that idiom, for a very similar use-case)...
> It will always be either a fixup or an accumulate/commit idiom, since there will always be a GlobalDecl ordering where the information to make 'the perfect module-global decision' isn't available upon having to act on partial information.
>
> In the end, I would like to have the verification of IFuncs having a defined resolver restored (and avoid more dependencies being taken on this being 'allowed' at the IR level), since having LLVM emit an object file with an undefined STT_GNU_IFUNC is probably just trouble and confusion waiting to happen.

The justification is that we're supposed to be able to (as best as we can) work in a REPL environment or similar, , like Cling(not a misspell) does. The idea is that we should be able to always be emitting 'valid' and 'final' IR so that we can generate source 1 declaration at a time and be valid.

We DO have things that break this (as you've mentioned), but the CFE's policy is to not break any additional cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112349



More information about the llvm-commits mailing list