[SystemZ] Significant compile time regression in LLVM 20 due to `isFullyInternal()`

[alexrp]

With LLVM 20, we're seeing significantly increased compile times for the Zig standard library test executable for s390x-linux: 0m33s with LLVM 19 vs 3m28s with LLVM 20. It appears to be caused by #100757 (FYI @JonPsson1 @uweigand), specifically this function:

llvm-project/llvm/lib/Target/SystemZ/SystemZISelLowering.cpp

Lines 10203 to 10217 in fa45bf4

	// Only consider a function fully internal as long as it has local linkage
	// and is not used in any other way than acting as the called function at
	// call sites.
	bool SystemZTargetLowering::isFullyInternal(const Function *Fn) const {
	if (!Fn->hasLocalLinkage())
	return false;
	for (const User *U : Fn->users()) {
	if (auto *CB = dyn_cast<CallBase>(U)) {
	if (CB->getCalledFunction() != Fn)
	return false;
	} else
	return false;
	}
	return true;
	}

And its (indirect) usage here:

llvm-project/llvm/lib/Target/SystemZ/SystemZISelLowering.cpp

Lines 2206 to 2207 in fa45bf4

	// Integer args <=32 bits should have an extension attribute.
	verifyNarrowIntegerArgs_Call(Outs, &MF.getFunction(), Callee);

In Zig we have a helper function std.builtin.returnError() that the compiler emits calls to when an error value is returned from a function. Since we use a compilation model that can roughly be described as a unity build, the standard library test module has around ~68,000 calls to this function. LLVM is now walking the full use list of this function at every call site, which is less than ideal.

[JonPsson1]

Hej Alex,

Thank you for the report. I would be happy to take a look. Could you post a reproducer (.bc / .ll file that works with llc)?

As this is off per default, I suspect that you are building with -argext-abi-check? As a quick solution you could ofc remove that flag, maybe except for some debug builds.

/Jonas

[alexrp]

Thank you for the report. I would be happy to take a look. Could you post a reproducer (.bc / .ll file that works with llc)?

Hmm, that might be rough. The compiled test executable is several hundreds of megabytes, so the IR/bitcode would presumably be even worse.

As this is off per default, I suspect that you are building with -argext-abi-check? As a quick solution you could ofc remove that flag, maybe except for some debug builds.

For concurrency reasons, Zig specifically avoids setting any LLVM command line flags of this sort.

But, it looks to me like isFullyInternal() is called in verifyNarrowIntegerArgs_Call() before EnableIntArgExtCheck is checked in the following call to verifyNarrowIntegerArgs().

[JonPsson1]

Hmm, that might be rough. The compiled test executable is several hundreds of megabytes, so the IR/bitcode would presumably be even worse.

I see.

But, it looks to me like isFullyInternal() is called in verifyNarrowIntegerArgs_Call() before EnableIntArgExtCheck is checked in the following call to verifyNarrowIntegerArgs().

Ah - you are right. I will propose a fix shortly.

[JonPsson1]

#130693

It would be great if you could try this patch and confirm that the regression is resolved.

[uweigand]

#130693

It would be great if you could try this patch and confirm that the regression is resolved.

I think we should first have a quick fix to make sure that the expensive operation is only performed if checking is enabled - this we'd also want to backport to LLVM 20 (e.g. by passing CalleeFn instead of IsInternal to verifyNarrowIntegerArgs). The more general fix including caching can then come on top later, and only on mainline.