Skip to content

[BOLT] Always run CheckLargeFunctions in non-relocation mode #80922

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 8, 2024

Conversation

maksfb
Copy link
Contributor

@maksfb maksfb commented Feb 7, 2024

We run CheckLargeFunctions pass in non-relocation mode to prevent the emission of functions that later could not be written to the output due to their large size. The main reason behind the pass is to prevent the emission of metadata for such functions since this metadata becomes incorrect if the function is left unmodified.

Currently, the pass is enabled in non-relocation mode only when debug info output is also enabled. As we emit increasingly more kinds of metadata, e.g. for the Linux kernel, it becomes more challenging to track metadata that needs to be fixed. Hence, I'm enabling the pass to always run in non-relocation mode.

We run CheckLargeFunctions pass in non-relocation mode to prevent the
emission of functions that later could not be written to the output due
to their large size. The main reason behind the pass is to prevent the
emission of metadata for such functions since this metadata becomes
incorrect if the function is left unmodified.

Currently, the pass is enabled in non-relocation mode only when debug
info output is also enabled. As we emit increasingly more kinds of
metadata, e.g. for the Linux kernel, it becomes more challenging to
track metadata that needs to be fixed. Hence, I'm enabling the pass to
always run in non-relocation mode.
@maksfb maksfb added the BOLT label Feb 7, 2024
@maksfb maksfb requested review from mtvec and yota9 February 7, 2024 01:59
@maksfb
Copy link
Contributor Author

maksfb commented Feb 7, 2024

@mtvec, @yota9, I have added a couple of asserts that are x86-only. I found out that they are firing on RISC-V and Aarch64 which means CheckLargeFunctions doesn't always work. I briefly looked at the failures and they were all related to constant islands. We will need to adjust the size calculation and fitting requirements accordingly.

@yota9
Copy link
Member

yota9 commented Feb 7, 2024

I agree, since currently we're calculating true size separately in LongJmp for aarch64 like
DotAddress = alignTo(DotAddress, Func->getConstantIslandAlignment());
DotAddress += Func->estimateConstantIslandSize();

It would be better to incorporate this code to BF-specific size calculation function

@@ -3631,6 +3631,7 @@ void RewriteInstance::mapCodeSections(BOLTLinker::SectionMapper MapSection) {
Function.setImageAddress(FuncSection->getAllocAddress());
Function.setImageSize(FuncSection->getOutputSize());
if (Function.getImageSize() > Function.getMaxSize()) {
assert(!BC->isX86() && "Unexpected large function.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yota9, @mtvec – would it be correct to check if the function has constant islands instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify the question, could you test it on your side with assertion changed to check for CIs? Ideally, the check should be properly modified to accommodate for CIs on supported architectures.

Copy link
Contributor

@aaupov aaupov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that the assertion is useful as-is and can later be enabled for other targets in a follow-up.

LGTM.

@maksfb maksfb merged commit 7fe97f0 into llvm:main Feb 8, 2024
@maksfb maksfb deleted the gh-main branch February 9, 2024 04:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants