Recognize -mrecord-mcount from the command line and add a function attribute "mrecord-mcount when passed.
Only valid on SystemZ when used with -mfentry.
Differential D71627
[Clang FE, SystemZ] Recognize -mrecord-mcount CL option. jonpa on Dec 17 2019, 1:54 PM. Authored by
Details
Recognize -mrecord-mcount from the command line and add a function attribute "mrecord-mcount when passed. Only valid on SystemZ when used with -mfentry.
Diff Detail Event TimelineComment Actions Probably better to only have one hard-coded space character in mrecord-mcount.c CHECK line. Comment Actions This is regressing linux kernel builds for multiple architectures. The linux kernel uses feature detection for compiler flags, basically invoking: $ clang -mrecord-mcount -target aarch64-linux-gnu -c -x c /dev/null Because the target info isn't validated until code gen, the above returns 0, which seems like the flag is supported, so it is used for further compilations which then do fail. Comment Actions I am not sure how this should be handled... Maybe you could open an issue on Bugzilla and add the right people on the CC list (I am not sure exactly who they would be...)? Comment Actions Can we simply move all the validity checks (arg only valid on SystemZ, or arg only valid in combination with another arg) into ParseCodeGenArgs in CompilerInvocation.cpp, where the args are initially looked at? Comment Actions While that is discussed, I think this commit should be reverted. All working Linux kernel allyesconfig builds with Clang are now broken with this commit because of what Nick pointed out (-mrecord-mcount gets added to the list of CFLAGS then the build fails when actual code generation starts). Comment Actions Fixed by 0792ef72564071f21b727d0de3a14d565950290f. My Linux powerpc64le build is good now. make ARCH=powerpc CROSS_COMPILE=powerpc64le-linux-gnu- CC=~/llvm/Release/bin/clang LD=~/llvm/Release/bin/ld.lld O=out/powerpc64le powernv_defconfig zImage.epapr -j 30 Comment Actions Thank for you the fix, and sorry for the disruption! There is another limitation of the current implementation: -mrecord-mcount / -mnop-mcount are only supported with -mfentry, not with the "regular" mcount profiling. This is just a limitation of the current implementation (but in any case, the Linux kernel build will only use it in this combination anyway). We currently have checks that this combination is specified, but those are also in the code generator. Should they be moved to the driver as well? Comment Actions gcc/config/s390/s390.c requires -mnop-mcount to be used together with -mfentry, but gcc/config/i386/i386-options.c doesn't. % clang -target s390x -pg -mnop-mcount -c a.c error: option '-mnop-mcount' cannot be specified without '-mfentry' 1 error generated. % gcc -pg -mnop-mcount -fno-pic -c a.c (GCC performs some other checks. I noted some in commit 527b0f8c7448707aa6b8159e6e4707a49f1dcb87, but I am not sure whether we should document all... These options are only used by Linux kernel, and more specifically, ftrace.) |