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

Erich Keane via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Nov 5 08:30:24 PDT 2021


erichkeane added a comment.

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

> And how is Cling expecting CFE to deal with partial knowledge situations at the implementation level? To deal with exactly the non-local cases that the current violations address?
> If there's no prescriptive way forward to dealing with these cases (so they're tech debt without a remediation plan), then as far as I'm concerned this case sits exactly under the same tech-debt umbrella of the existing violations and the way forward is using the same violating solution for this case too. 
> We definitely shouldn't block the IR verification indefinitely on this impasse. Once an acceptable solution is found, this will also be part of that refactor.

My understanding is that the REPL setup is that the 'IR' just needs to be in a state where it doesn't require reverts/rewrites later, so that we can do partial-back-end-code-generation as we go along.  That said, I'm not positive as to the implications.  I'm just repeating the discussion the CFE code-owner made at the time.

IMO, the 'acceptable' solution is to have a way to forward-declare an ifunc in IR so that we can fill in the resolver later on.  From your description earlier, it seems that this would work as we could emit it as an 'unknown symbol' (as if it was an undefined function declaration), and would be completely implementable in the CFE.

So it would change your plan from earlier to:

When processing cpu_specific, emit the ifunc "x.ifunc", with no resolver;
When processing cpu_dispatch:

  Get/Create the ifunc, then pull up the resolver.
  If the resolver is null (as it should be), create one and update the 'ifunc'.
  Generate said resolver.
  



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