This is an archive of the discontinued LLVM Phabricator instance.

[Passes] Don't add CHR pass for CSIRInstr build in PostLink
Needs ReviewPublic

Authored by xur on Nov 18 2022, 3:07 PM.

Details

Reviewers
tejohnson
Summary

Don't add ControlHeightReductin (CHR) pass for CSIRInstr build in the PostLink because the profile is the same as the PreLink compilation.

Diff Detail

Event Timeline

xur created this revision.Nov 18 2022, 3:07 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 18 2022, 3:07 PM
Herald added a subscriber: hiraditya. · View Herald Transcript
xur requested review of this revision.Nov 18 2022, 3:07 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 18 2022, 3:07 PM
davidxl added inline comments.Nov 18 2022, 3:12 PM
llvm/lib/Passes/PassBuilderPipelines.cpp
607

Can you explain this comment more?

Also push the comment closer to the actual line.

Where is the CSFDO annotation step in relation to this pass? If it would be annotated before this point on the subsequent CSFDO use compile, is the idea that we might as well wait for the CSFDO profile before performing post-link CHR?

Presumably even if the profile is the same as the pre-link CHR, the code could be different after cross-module importing, inlining, other cleanup, so wouldn't that open up more opportunities potentially for CHR?

xur added a comment.Nov 21 2022, 2:01 PM

Where is the CSFDO annotation step in relation to this pass? If it would be annotated before this point on the subsequent CSFDO use compile, is the idea that we might as well wait for the CSFDO profile before performing post-link CHR?

Presumably even if the profile is the same as the pre-link CHR, the code could be different after cross-module importing, inlining, other cleanup, so wouldn't that open up more opportunities potentially for CHR?

Thanks for asking this. I was under the impression that CHR pass was after CSFDO instrumentation and use. But when I checked the code, this was not the case. CHR is in FunctinSimplicaiton pipeline which is before ModuleOptimization pipeline where CSFDO happens.

I don't know the reason for doing CHR early -- CHR can increase the code size and thus affect inlining. Doing it later in the pipelie might make more sense.

As for this patch, now I would disable CHR for CSFDO instrumentation and use because the size increase for CSFDO (after inline) is out of control.
But this is not strictly needed if we have https://reviews.llvm.org/D138333.

as mentioned in D138333, +1 to moving CHR from the simplification pipeline to the optimization pipeline