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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
