-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
[AArch64] Random things are broken after AArch64CollectLOH: Rewrite as block-local analysis.
#30709
Comments
assigned to @MatzeB |
I think I already got an internal report about a similar issue. And I believe it requires https://reviews.llvm.org/D27559 to be fixed. I'll revert for now as there don't seem to be any reviews coming in on that other patch. |
Reverted in r289570 for now. |
Someone over here tried https://reviews.llvm.org/D27559 on top of your change and apparently it didn't help. Running stuff on iOS apparently requires certs and whatnot and I can't do it, but one failing test was this EXPECT_EQ: So you can probably repro by having two files a.cc b.cc looking roughly like so: $ cat a.cc for (size_t i = 0; i < arraysize(cases); ++i) { // Faster specialization for bases <= 10 // Specialization for bases where 10 < base <= 36 template <int BASE, typename CHAR> As far as I can tell, we build with -O2 and some other flags (partial list |
I could not reproduce the problem with this. After fixing some smallish syntax errors I get the same results with/without the patches except for a different order of the .loh statements which has no effect. Thinking about what could go wrong, looks like https://reviews.llvm.org/D27558 is probably also required to fix potentially wrong live-in blocks. Anyway I suggest waiting until the reviews on those patches are done and I landed the series in tree and then test again. |
We now have a bot that builds chrome/iOS with clang trunk continously. It was green but then ~all tests started failing again. The last good run was at r290024, the first bad with r290033. Your reland is r290026, so it looks like it still breaks things. So you probably want to revert again :-( I apologize for not getting you a good repro. I'll try to obtain an iOS device on Monday and get you one myself. |
Sorry for breaking you again, I wish one of LNT or test-suite bots would catch the bug but apparently not. In the mean time reverted in r290047. |
Current status:
(I'm actively looking at this but the iOS part is putting up more fight than expected, sorry) |
Hooray, I managed to run the test on an iPhone device and I managed to reproduce the test failure. I'm reducing now. If anyone wants to follow along at home, follow https://chromium.googlesource.com/chromium/src/+/master/docs/ios_build_instructions.md up to "Setting up the build". Then edit out/Release-iphoneos/args.gn to look like: is_debug = false clang_use_chrome_plugins = false Then |
It's proving somewhat difficult to reduce. Here's what I have so far (I'll keep trying), maybe that's already enough to give you an idea. I'm down to 15 seemingly unrelated files in base_unittests (plus still all of its dependencies) -- https://codereview.chromium.org/2595063002/ if you're really curious. It feels like a certain size is needed so that string literal addressing is done via adrp/add instead of just ldr'ing off an immediate address. (I'll try to get the same effect by putting in generated filler stuff.) Take a look at the RHS of https://codereview.chromium.org/2595063002/diff/1/base/strings/string_number_conversions_unittest.cc , the failing test (also shown in comment 3). The first thing it does is load a few string literals into std::strings on the stack ( In a working binary, with your change reverted, this looks for example like so: 0000000100006d10 adrp x9, 256 ; 0x100006000 and so on. Strings are loaded pc-relative, and the stored to the stack in very few instructions thanks to the wide amd64 registers. Here's the same snippet with your patch applied: 0000000100006d9c adrp x9, 256 ; 0x100006000 This looks really similar, except that the pc-rel load of the "output" array ( 0000000100006d24 adrp x9, 256 ; 0x100006000 to 0000000100006db0 nop -- the adrp got lost! I think that's the root cause, but I haven't reduced things yet. If I use clang with your patch applied and try to reduce the number of code in the repro case more, then the above becomes something like 0000000100007218 ldr q0, 0x100106e98 i.e. this now uses either ldr to load an immediate address, or uses adr instead of adrp because the string literal is close enough to pc that that can work, and that hides the problem. Does this ring any bells? |
This seems to be on the right track. If I add another function that expands to > 1MB of code then I can remove all other source files from base_unittests and still repro. Here's my one file in base_unittests (it still links to a bunch of static libraries for now, but I'm relatively confident I can reduce unhindered from now): #include "base/strings/string_number_conversions.h" #include #include "testing/gtest/include/gtest/gtest.h" namespace base { TEST(StringNumberConversionsTest, HexStringToBytes) { for (size_t i = 0; i < arraysize(cases); ++i) { TEST(StringNumberConversionsTestPadding, FooBar) { } // namespace base |
(thanks to pcc who mentioned that code stuffing trick on irc) |
A'ight, this two-file program prints "shame" and exit(1)s with your patch and just runs fine without it. I'm also pasting the full build log, some of which is our goop for setting up a dummy iOS bundle to run regular executables on iOS. You probably have something similar. The only thing really interesting for you is compiler and linker flags, I'm guessing. I think this should be enough for you to repro, let me know if you need more. thakis-macpro:src thakis$ cat base/strings/string_number_conversions.cc bool CharToDigit(char c, uint8_t* digit) { bool HexStringToBytes(const std::string& input, std::vector<uint8_t>* output) { void f() { thakis-macpro:src thakis$ cat base/strings/string_number_conversions_unittest.cc bool HexStringToBytes(const std::string& input, std::vector<uint8_t>* output); int main() { for (size_t i = 0; i < sizeof(cases) / sizeof(cases[0]); ++i) {
} volatile int i = 0; if (i) f(); // Don't dead-strip f. thakis-macpro:src thakis$ time ninja -C out/Release-iphoneos/ base_unittests -v |
Oh, and comment 9 explains why this is crashing. Why that adrp is getting lost isn't clear though :-) |
It looks like it's still there in the .o file. I also can't reproduce this in an Android arm64 build. Maybe this is running into some ld64 relocation processing bug? |
Thanks for reducing this, I'll dive into it in the next days. For context: The whole LOH pass computes extra information for the linker that allows it to remove some instructions that become unnecessary after resolving relocations. AArch64CollectLOH.cpp has explanations at the beginning if you are interested in more details. This optimization is only available for mach-o so android is not affected. |
I am still unable to reproduce this in my setup :-( Could you do the following for me:
$ export SYSROOT="$(xcrun --sdk iphoneos --show-sdk-path)" $ clang++ -DV8_DEPRECATION_WARNINGS -DNO_TCMALLOC -DDISABLE_NACL -DCHROMIUM_BUILD -DFIELDTRIAL_TESTING_ENABLED -DCR_CLANG_REVISION=289944-1 -DCR_XCODE_VERSION=0810 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -I../.. -Igen -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -fcolor-diagnostics -arch arm64 -Wall -Werror -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-covered-switch-default -Wno-deprecated-register -Wno-unneeded-internal-declaration -Wno-inconsistent-missing-override -Wno-shift-negative-value -Wno-undefined-var-template -Wno-nonportable-include-path -Wno-address-of-packed-member -Os -gdwarf-2 -isysroot ${SYSROOT} -stdlib=libc++ -miphoneos-version-min=9.0 -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -fno-threadsafe-statics -fvisibility-inlines-hidden -std=c++11 -fno-rtti -fno-exceptions -emit-llvm -S string_number_conversions_unittest.cc -o string_number_conversions_unittest.ll
|
The .ll file should look the same with or without my patch. However you should get a valid/invalid executable when you run them through codegen with/without my patch. Commands to do that should look like this: $ SYSROOT="$(xcrun --sdk iphoneos --show-sdk-path)" |
as requested in comment 16 thakis-macpro:newdir thakis$ ls -lh |
Good news, I can repro you not being able to repro :-P I can attach those compiled files if you think it's helpful, but I'm guessing it won't be. I can attach a good and a bad "real" binary if you think it's useful (it might be). I'll try to figure out why this repros in our full build but not with the simple commands you pasted. Will report back later today. |
If I change your commands to a) produce .o files instead of .s files b) include more of the compilery flags from the compile commands I pasted, it seems to repro for me. With the .ll files I attached: $ ~/src/llvm-build2/bin//clang++ -c --param=ssp-buffer-size=4 -fstack-protector -fcolor-diagnostics -arch arm64 -Os -gdwarf-2 -isysroot ${SYSROOT} -stdlib=libc++ -miphoneos-version-min=9.0 -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -fno-threadsafe-statics -fvisibility-inlines-hidden -std=c++11 -fno-rtti -fno-exceptions string_number_conversions_unittest.ll -o string_number_conversions_unittest.o |
Thanks for reducing the testcase. I was able to reproduce and fix the issue. Committed again as r291266. Please re-open if there are further problems. |
Our bot cycled green this time. Thanks! |
Extended Description
Random things are broken in Chromium after rolling past trunk@288561
AArch64CollectLOH: Rewrite as block-local analysis
Most of the mysterious errors are causing crashes, some random string manipulation errors.
Repo coming once we have it.
The text was updated successfully, but these errors were encountered: