@uweigand, thanks again for confirming the patch works for you. The differential revision is here https://reviews.llvm.org/D102756

In D96033#2766141, @uweigand wrote:

In D96033#2765954, @v.g.vassilev wrote:

@hubert.reinterpretcast, thanks for the feedback. I have created a patch as discussed -- https://reviews.llvm.org/D102688

@uweigand, thanks for reaching out. I believe the patch above should fix your setup. Could you confirm?

Unfortunately, it does not. Changing the triple doesn't affect the architecture the compiler generates code for. If you wanted to change the compiler to generate code for the architecture the JIT detects, the easiest way would probably be to use (the equivalent of) "-march=native", which causes the compiler to also auto-detect the current processor in the same way as the JIT does.

In D96033#2766332, @phosek wrote:

We've started seeing LLVM ERROR: out of memory on our 2-stage LTO Linux builders after this change landed. It looks like linking clang-repl always fails on our bot, but I've also seen OOM when linking ClangCodeGenTests and FrontendTests. Do you have any idea why this could be happening? We'd appreciate any help since our bots have been broken for several days now.

@hubert.reinterpretcast, thanks for the feedback. I have created a patch as discussed -- https://reviews.llvm.org/D102688

In D96033#2762134, @hubert.reinterpretcast wrote:

In D96033#2762056, @v.g.vassilev wrote:

IIUC, AIX has a default fno-integrated-as and I am still puzzled (and cannot find the relevant code) what is the program action kind for AIX in that case (frontend::???).

This is rooted in IsIntegratedAssemblerDefault and the relevant code is more a relevant lack of code. The default implementation, ToolChain::IsIntegratedAssemblerDefault, returns false.

Maybe applying that diff can give us a hint:

Output is:

$ cat /home/hstong/.Liodine/llvmproj/clang/test/Interpreter/execute.cpp | /home/hstong/.Nrtphome/.Liodine/llcrossbld/dev/build/bin/clang-repl
ActionKind=7
clang-repl: Driver initialization failed. Incremental mode for action is not supported

In D96033#2761581, @hubert.reinterpretcast wrote:

In D96033#2761428, @hubert.reinterpretcast wrote:

If you have some ideas, please let me know. Meanwhile, I am trying out system-aix as the "feature" to XFAIL on.

https://reviews.llvm.org/D102560 posted to use system-aix so other PPC configurations will run the test. Possible further changes is for the code to choose the process triple, for the test to possibly specify -fintegrated-as, and (alternatively) for the system assembler step to be integrated into this use scenario.

In D96033#2760067, @hubert.reinterpretcast wrote:

In D96033#2759808, @v.g.vassilev wrote:

Hi @hubert.reinterpretcast,

Would you mind testing this patch:

Does the test try to generate native object files in some way? There is functionality (with some limitations) for that under 32-bit AIX; however, we're running a 64-bit build and we don't have integrated-as capability for that at this time. This is what I'm seeing:

******************** TEST 'Clang :: Interpreter/execute.cpp' FAILED ********************
Script:
--
: 'RUN: at line 1';   cat /home/hstong/.Liodine/llvmproj/clang/test/Interpreter/execute.cpp | /home/hstong/.Nrtphome/.Liodine/llcrossbld/dev/build/bin/clang-repl | /home/hstong/.Nrtphome/.Liodine/llcrossbld/dev/build/bin/FileCheck /home/hstong/.Liodine/llvmproj/clang/test/Interpreter/execute.cpp
--
Exit Code: 2

Command Output (stderr):
--
clang-repl: Driver initialization failed. Incremental mode for action is not supported
FileCheck error: '<stdin>' is empty.
FileCheck command line:  /home/hstong/.Nrtphome/.Liodine/llcrossbld/dev/build/bin/FileCheck /home/hstong/.Liodine/llvmproj/clang/test/Interpreter/execute.cpp

--

********************

Would you mind testing this patch:

diff
diff --git a/clang/lib/Interpreter/Interpreter.cpp b/clang/lib/Interpreter/Interpreter.cpp
index 8de38c0afcd9..79acb5bd6898 100644
--- a/clang/lib/Interpreter/Interpreter.cpp
+++ b/clang/lib/Interpreter/Interpreter.cpp
@@ -157,7 +157,7 @@ IncrementalCompilerBuilder::create(std::vector<const char *> &ClangArgv) {
   ParseDiagnosticArgs(*DiagOpts, ParsedArgs, &Diags);

Thanks to @Hahnfeld, that's not needed anymore.

In D96033#2757107, @v.g.vassilev wrote:

In D96033#2757077, @hubert.reinterpretcast wrote:

@v.g.vassilev, the test does not appear to be appropriately set up for builds that default to a non-native target:
https://lab.llvm.org/staging/#/builders/126/builds/371/steps/5/logs/FAIL__Clang__execute_cpp

Can you fix or revert until there is a fix?

Apologies. Do you know if REQUIRES: native is sufficient to fix (trying to avoid churn)?

In D96033#2757077, @hubert.reinterpretcast wrote:

@v.g.vassilev, the test does not appear to be appropriately set up for builds that default to a non-native target:
https://lab.llvm.org/staging/#/builders/126/builds/371/steps/5/logs/FAIL__Clang__execute_cpp

Can you fix or revert until there is a fix?

Thanks everybody for reviewing and help making this patch better!!

clang-tidy and clang-format

Thanks, @teemperor. I have addressed your last comments, too.

• Check if we can use death tests;
• Do not install clang-repl as being an early stage development.

In D96033#2717749, @teemperor wrote:

Sorry for the delay. I think all my points have been resolved beside the insertion SourceLoc.

Address source location comment of teemperor.

@rsmith ping2...

@rsmith ping...

@teemperor, could you take another look at this patch -- I believe most of your concerns are addressed now.

In D96033#2695748, @rjmccall wrote:

In D96033#2695622, @v.g.vassilev wrote:

Would it make sense to have each Decl point to its owning PTU, similarly to what we do for the owning module (Decl::getOwningModule)?

I think that's the interface we want, but actually storing the PTU in every Decl that way is probably prohibitive in memory overhead; we need some more compact way to recover it. But maybe it's okay to do something like that if we can spare a bit in Decl. Richard, thoughts here?

Thank you for the details -- will be really useful to me and that architecture will define away several hard problems we tried to solve over the years.

Nice catch! Thanks!

ping...

@teemperor, should we land this?

@hamzasood, I suppose this is still worth pursuing. Could you address the comment?

@rjmccall, @rsmith, ping...

We probably need to talk about it.

+1. Do you use discord/slack/skype?

Adding Jonas as our Arm JIT expert (as per https://github.com/cms-sw/cmssw/issues/31123)

In D96033#2632848, @rjmccall wrote:

In D96033#2630978, @v.g.vassilev wrote:

I'm nervous in general about the looming idea of declaration unloading, but the fact that it's been working in Cling for a long time gives me some confidence that we can do that in a way that's not prohibitively expensive and invasive.

I don't really know the jargon here.

"Code unloading" is mentioned here https://reviews.llvm.org/D96033?id=323531#inline-911819

I see. So you want to be able to sort of "roll back" Sema to a previous version of the semantic state, and yet you also need IRGen to *not* be rolled back because of lazy emission.

argh... I only now see the pre-merge suggestions -- almost all of them seem not super essential -- let me know if I should address them in a subsequent commit...

I'm nervous in general about the looming idea of declaration unloading, but the fact that it's been working in Cling for a long time gives me some confidence that we can do that in a way that's not prohibitively expensive and invasive.

I don't really know the jargon here.

Formatting.

Address comments -- rename test file; add a logging diagnostic consumer.

Address most of the formatting suggestions.

Add changes proposed by @rsmith, add an assertion for duplicate entries.

• Do not rely on process exit code for --host-supports-jit but parse the true/false flag.

Add a lit feature to check if llvm has jit support to selectively run tests.

Adjust the two tests I failed to merge.

More fixes suggested by @rsmith

Address Lang's comments.

Make visitation of multiversion functions independent on the lookup ordering; adjust tests.

Address some of Richard's comments.

Address comments from Raphael and Stefan.

Hi Stefan,

Address more review comments.

@teemperor, thanks for the hints.

Address comments.

Address most of the comments.

Add documentation, resolve address comments, update in-tree clients.

Minor typos, conciseness..

Store current state, address some comments, a few bugs still to address...

Upload the current changes. I need to update the users such as lldb, clang-tools-extra and clangd. It has some rough edges wrt modules.

Invert the diff, fix a typo.

Take another approach at solving this issue. Instead we are making the lookup_result safe.

@rsmith, what was the fate of this patch? I thought it landed but cannot find a trace of it in the master...

Landed in aca191cce1c4dbab28a65cfe4caa6348e698a2b3

Closing this in favor of D77598

Landed as D54986