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