Agree with tmsriram@ the quadratic behaviour needs to be addressed, though I think we should split it out as a separate change which can be committed first. That would make it easier for folks to review independently. Thanks!
May 24 2021
May 13 2021
lgtm, however please wait a bit for any follow up comments from other reviewers. Thanks!
Apr 28 2021
Apr 23 2021
Apr 21 2021
Revert hasSection() since it is not semantically equivalent to getSection().empty().
Use hasSection() in the condition.
Mar 30 2021
Mar 29 2021
Mar 22 2021
Yes, definitely adding it in a separate patch is a good idea :) Lets submit that patch first, before we submit with this one (otherwise any large binary generated by this patch is probably going to be broken).
It should include the necessary code changes for windows unwind info. I think the code modifications for that change should be in files: llvm/llvm-project/llvm/lib/MC/MCWin64EH.cpp and llvm/llvm-project/llvm/lib/CodeGen/AsmPrinter/WinException.cpp (this one will have changes for C++ programs with exceptions enabled).
Mar 19 2021
Hi Tao, since it looks like you are making progress on this! I would suggest adding the Windows exception handling test for basic block sections instead of MFS in particular. It will simplify the test since you don't need profile information and we will get better confidence for the Propeller framework overall. It would be equivalent to this test: llvm/test/CodeGen/X86/basic-block-sections-eh.ll
Feb 17 2021
As for Windows COFF, is it also not MFS but MFS dependent basic block sections may be incorrect for Windows native debuggers, so need to extend basic block sections debug info test at first?
Thanks for reminding the discussion of not adding a separate debug info test for function splitting! I’ll merge the test into test/DebugInfo/X86/basic-block-sections_1.ll.
Please do not merge this test. Apologies if I was unclear earlier - there is no need for this test since the functionality is already tested in test/DebugInfo/X86/basic-block-sections_1.ll
The machine function splitter (MFS) pass uses basic block sections so if the dwarf debug info generated by basic block sections is correct then MFS is also correct.
Feb 11 2021
Feb 10 2021
Thanks for the review.
Spell out types instead of auto.
We have discussed this approach and decided against adding a separate debug info test for function splitting (see the discussion in D90717). The underlying functionality is tested in test/DebugInfo/X86/basic-block-sections_1.ll. Based on the direction in your previous patch (D95209) - emitting dwarf based debug info for PE/COFF executables has limited utility as far as I can tell. While tooling under cygwin will be able to use this information most Windows native debuggers may not support reading from dwarf (eg. libdwarf started supporting PE mid-2019: https://www.prevanders.net/dwarf.html#libdwarf-20190104). For Windows, we need to look into the CodeView format (see the slides from https://llvm.org/devmtg/2016-11/Slides/Kleckner-CodeViewInLLVM.pdf).
I tried this patch on an instrumented build of mysql server. With this patch, an additional 28KB of text is split out from hot functions, a small but non-trivial improvement considering the size of the .text.hot section is ~1MB.
Feb 9 2021
Yes, this would cause an issue if we had hot and cold landing pads. I've updated the logic to account for this and added a test. PTAL, thanks!
Extend the check to account of multiple landing pads with difference in hotness.
Add a new test to verify the expected behaviour.
Can you elaborate on the motivation behind this test?
Added FIXME to clarify that Labels and splitting can be enabled together but we don't support it yet.
Jan 28 2021
Jan 26 2021
IMHO we should not ship the split functions feature targeting COFF without more testing. The machine function splitter relies on basic block sections and we should ensure that the debug information/call frame information generated by basic block sections is appropriate for COFF based consumers. Perhaps we can start by extending the existing CFI and DebugInfo tests in llvm/test/CodeGen/X86/cfi-basic-block-sections-1.ll and llvm/test/DebugInfo/X86/basic-block-sections_1.ll (in a separate patch).
Dec 8 2020
Can we add a test for this?
Nov 9 2020
Thanks for the review David. I've added the addresses to the test for now. Extending the verbose output for dwarfdump seems like a good idea, we will look into adding that in the future.
Check addresses as well, simplify triple.
Nov 6 2020
Nov 5 2020
Thanks for the review all. I've updated the test to use llvm-dwarfdump to check that the line table is as expected for the hot and cold parts.
Updates based on review comments.
Nov 3 2020
Add UNSUPPORTED tag for windows and mac os.
Oct 26 2020
lgtm, thanks for adding the test.
Oct 24 2020
Oct 23 2020
Oct 15 2020
Oct 14 2020
Oct 13 2020
Thanks for the review.
Add comments, rebase.
Oct 8 2020
Thanks for the review.
Update prefix to .text.split.
Spell out TTI as TargetTransformInfo, rebase.
Update comment and rebase.
This pass is only enabled on X86 platforms (D87047 for clang options and platform check). Longer term it does make sense to move it to TTI so I've added a FIXME to get this change off the critical path and I'll follow up with a refactoring change.
Add a FIXME to move defaults to TTI.
Oct 7 2020
Updated tests to use .text.split. prefix.
Oct 6 2020
lgtm with some minor comments.
Sep 25 2020
Let me look into module flags a little bit and I'll come back to this patch once I have a better understanding. Thanks for the comments!
Sep 24 2020
Thanks for the review.
Update comment, test.
Updated description and tests, PTAL thanks!
Update description, add test.
Update git commit message to specify option.
Add another check for the test.
Document flag, tighten test, rename var and option for clarity.
Lets push this if it's good to go?
Sep 22 2020
Is it expected that the user will want to specify this only at link time and not during compile time? If it is normally specified in the compile step, you should consider adding it to the IR in some fashion (e.g. function attributes). The advantage is that the user doesn't need to pass different options for the LTO and non-LTO cases.
Ideally we should only have to specify this once. However, using function attributes doesn't seem ideal since the pass will be scheduled and repeatedly invoked only to return without actually running the pass. It would be cleaner to marshal the codegen specific options from the compile invocation and restore them for the LTO step. There are a couple of other codegen options which would also benefit from this approach --lto-unique-basic-block-section-names, --lto-basic-block-sections=<value>. @mtrofin pointed out that -fembed-bitcode saves the invocation in .llvmcmd. A similar approach to stash codegen specific options always for LTO to pick up and enable might be less intrusive. However, this is a larger effort and for current LTO builds it would be nice to have a command line option to enable it. WDYT about this alternative?
Sep 21 2020
Rebase and update git commit message.