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

[Vassil Vassilev via Phabricator via cfe-commits]

v.g.vassilev added a comment.

In D112349#3111927 <https://reviews.llvm.org/D112349#3111927>, @erichkeane wrote:

> 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.
>   

Speaking of the incremental compilation case, we can experiment with the clang-repl binary. I am not sure about the details of this discussion but here is an example that works today:

  llvm/build/bin/clang-repl 
  clang-repl> __attribute__((cpu_specific(ivybridge))) void single_version(void){}
  clang-repl> void useage() {single_version();}
  clang-repl> quit

What would it be a good example to check if the incremental compilation case is covered?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112349