Happy New Year, Than. So I have rebuilt llvm-goc, after applying https://go-review.googlesource.com/c/gollvm/+/270219 <http://this patch>. Here <https://drive.google.com/file/d/1qDSKwKORZjH824gVeSXUknVm0rpKZ9j-/view?usp=sharing> is my compressed build folder.
I am using $ clang --version clang version 12.0.0 Target: i686-pc-linux-gnu Thread model: posix on $ uname -a Linux oceanfish81-A8He 4.15.0-129-generic #132-Ubuntu SMP Thu Dec 10 14:07:35 UTC 2020 i686 i686 i686 GNU/Linux You can obtain a pre-compiler "MinSizeRel" build of LLVM (including Clang) here <https://drive.google.com/file/d/1c7wredQbaX4p20Ee15WnY3SblbjiQHMD/view?usp=sharing> . I tried to build an avarage libgo package - and here is what I got: $ ninja libgo_golang.org_x_crypto_chacha20 [1/120] Building Go package 'unicode' (non-PIC) FAILED: tools/gollvm/libgo/unicode.o cd /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo && /usr/local/bin/cmake -E make_directory ./. && /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc -c -o /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo/./unicode.o -fgo-pkgpath=unicode -I . /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/casetables.go /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/digit.go /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/graphic.go /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/letter.go /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/unicode/tables.go currently Gollvm is not supported on architecture i686 /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc: *unable to determine target CPU features for target i686-pc-linux-gnu* [2/120] Building Go package 'internal/unsafeheader' (PIC) FAILED: tools/gollvm/libgo/internal/.pic/unsafeheader.o cd /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo && /usr/local/bin/cmake -E make_directory ./internal/.pic && /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc -c -o /home/oceanfish81/Desktop/workarea/release/tools/gollvm/libgo/internal/.pic/unsafeheader.o -fPIC -fgo-pkgpath=internal/unsafeheader -I . /home/oceanfish81/Desktop/workarea/llvm-project/llvm/tools/gollvm/gofrontend/libgo/go/internal/unsafeheader/unsafeheader.go currently Gollvm is not supported on architecture i686 /home/oceanfish81/Desktop/workarea/release/./bin/llvm-goc: *unable to determine target CPU features for target i686-pc-linux-gnu* ninja: build stopped: subcommand failed. Ivan On Tuesday, December 8, 2020 at 3:30:05 PM UTC+2 th...@google.com wrote: > Hello, > > Thanks for the note. > > I am still not completely sure what the problem is. > > > You wrote: > > | I found > | > | // triple: i686-pc-linux-gnu > | static const CpuAttrs attrs1[] = { > | // first entry is default cpu > | { "i686", "+cx8,+x87"}, > | > | and (inside the hashmap) > | > | { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"}, > | , which is not what I have supported (for Intel Celeron M440). > > What makes you say that this is not what you have supported? Are you > saying that the cpu clang calls "yonah" doesn't actually have one of these > features (ex: sse3)? > > > | Clang reports "unsupported CPU features" on any non-provided one. > | So that is one big problem. > > Not sure what you mean here. Can you please post the complete clang > invocation and error message you are getting? > > > > | const TripleCpus triples[] = { > | { "x86_64-unknown-linux-gnu", &attrs0[0] }, > | { "i686-pc-linux-gnu", &attrs1[0] }, > | { "aarch64-unknown-linux-gnu", &attrs2[0] }, > | { "", nullptr } // sentinel > | }; > | is not targeting to yonah, while llc is targeting it. > | It is always some "default" CPU model and, in fact, your code never > provided extraction of the CPU model (from llc). > | > > When llc emits the line > > Host CPU: yonah > > this does not mean that clang/llc will automatically target 'yonah' when > compiling, it just means that the program has detected the host CPU. > > Generally speaking if you want clang to produce code targeted specifically > to the host CPU, you have to use -march=native or -mtune-native. > > Thanks, Than > > On Fri, Dec 4, 2020 at 8:08 PM Ivan Serdyuk <local.tou...@gmail.com> > wrote: > >> Hello. >> >> This issue is related to >> https://go-review.googlesource.com/c/gollvm/+/274574 >> . >> >> I think I have some misunderstanding on how you used to deal with CPU >> models, for LLVM. >> >> First things first - I had success with using >> >> #include "llvm/ADT/StringRef.h" >> #include "llvm/ADT/StringMap.h" >> #include "llvm/MC/SubtargetFeature.h" >> #include "llvm/Support/Host.h" >> >> using namespace llvm; >> SubtargetFeatures Features1; >> >> int main (int argc, char **argv) >> { >> sys::getHostCPUName(); >> StringMap HostFeatures; >> if (sys::getHostCPUFeatures(HostFeatures)) >> for (auto &F : HostFeatures) >> Features1.AddFeature(F.first(), F.second); >> >> printf("test %s", Features1.getString().c_str()); >> printf("\nsomething else\n"); >> return 0; >> } >> . It gives me such a set of CPU features: >> >> >> +sse2,-tsxldtrk,-cx16,-sahf,-tbm,-avx512ifma,-sha,-gfni,-fma4,-vpclmulqdq,-prfchw,-bmi2,-cldemote,-fsgsbase,-ptwrite,-amx-tile,-avx512bf16,-popcnt,-aes,-avx512bitalg,-movdiri,-xsaves,-avx512er,-xsavec,-avx512vnni,-amx-bf16,-avx512vpopcntdq,-pconfig,-clwb,-avx512f,-clzero,-pku,+mmx,-lwp,-rdpid,-xop,-rdseed,-waitpkg,-movdir64b,-sse4a,-avx512bw,-clflushopt,-xsave,-avx512vbmi2,-64bit,-avx512vl,-serialize,-invpcid,-avx512cd,-avx,-vaes,+cx8,-fma,-rtm,-bmi,-enqcmd,-rdrnd,-mwaitx,-sse4.1,-sse4.2,-avx2,+fxsr,-wbnoinvd,+sse,-lzcnt,-pclmul,-prefetchwt1,-f16c,-ssse3,-sgx,-shstk,+cmov,-avx512vbmi,-amx-int8,-movbe,-avx512vp2intersect,-xsaveopt,-avx512dq,-adx,-avx512pf,+sse3 >> >> $ llc --version >> provides >> Default target: i686-pc-linux-gnu >> Host CPU: yonah >> . >> >> I tried to update the capture-fcn-attributes.go file, like this: >> >> var supportedTriples []string = []string{ >> "x86_64-unknown-linux-gnu", >> "i686-pc-linux-gnu", >> "aarch64-unknown-linux-gnu", >> } >> . >> >> When I tried the generator >> >> capture-fcn-attributes -o /tmp/cpu_feature_list >> it generated me a broad list. >> The header contained >> >> Ubuntu clang version 11.0.0-++20200721055954+cebd637c886-1exp1 >> 20200721161335.13 >> . >> I found >> >> // triple: i686-pc-linux-gnu >> static const CpuAttrs attrs1[] = { >> // first entry is default cpu >> { "i686", "+cx8,+x87"}, >> >> and (inside the hashmap) >> >> { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"}, >> , which is not what I have supported (for Intel Celeron M440). >> Clang reports "unsupported CPU features" on any non-provided one. >> So that is one big problem. >> Next problem is that >> >> const TripleCpus triples[] = { >> { "x86_64-unknown-linux-gnu", &attrs0[0] }, >> { "i686-pc-linux-gnu", &attrs1[0] }, >> { "aarch64-unknown-linux-gnu", &attrs2[0] }, >> { "", nullptr } // sentinel >> }; >> is not targeting to yonah, while llc is targeting it. >> It is always some "default" CPU model and, in fact, your code never >> provided extraction of the CPU model (from llc). >> >> To make my observation complete - I am providing what is generated via >> >> capture-fcn-attributes -cpu yonah >> : >> >> // triple: x86_64-unknown-linux-gnu >> static const CpuAttrs attrs0[] = { >> // first entry is default cpu >> { "x86-64", "+cx8,+fxsr,+mmx,+sse,+sse2,+x87"}, >> { "", "" } // sentinel >> }; >> >> // triple: i686-pc-linux-gnu >> static const CpuAttrs attrs1[] = { >> // first entry is default cpu >> { "i686", "+cx8,+x87"}, >> { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"}, >> { "", "" } // sentinel >> }; >> >> // triple: aarch64-unknown-linux-gnu >> static const CpuAttrs attrs2[] = { >> // first entry is default cpu >> { "generic", "+neon"}, >> { "", "" } // sentinel >> }; >> >> const TripleCpus triples[] = { >> { "x86_64-unknown-linux-gnu", &attrs0[0] }, >> { "i686-pc-linux-gnu", &attrs1[0] }, >> { "aarch64-unknown-linux-gnu", &attrs2[0] }, >> { "", nullptr } // sentinel >> }; >> . >> >> I tried >> >> capture-fcn-attributes -cpu yonah -triples i686-pc-linux-gnu >> and got >> >> // triple: i686-pc-linux-gnu >> static const CpuAttrs attrs0[] = { >> // first entry is default cpu >> { "i686", "+cx8,+x87"}, >> { "yonah", "+cx8,+fxsr,+mmx,+sse,+sse2,+sse3,+x87"}, >> { "", "" } // sentinel >> }; >> >> const TripleCpus triples[] = { >> { "i686-pc-linux-gnu", &attrs0[0] }, >> { "", nullptr } // sentinel >> }; >> . >> >> I understand that your strategy worked find on Intel based >> system-on-board machines - but didn't try something for AMD (yet). >> Nevertheless I have these issues on i686 - so I am proposing to perform a >> review. >> >> >> Ivan >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/aac8c576-9763-4bba-96a1-51f545084630n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/aac8c576-9763-4bba-96a1-51f545084630n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/82983f33-0d64-4b12-b0d7-4596004165aan%40googlegroups.com.
