Ping On Friday, January 1, 2021 at 5:45:02 AM UTC+2 Ivan Serdyuk wrote:
> Happy New Year, Than. > > So I have rebuilt llvm-goc, after applying > https://go-review.googlesource.com/c/gollvm/+/270219. > 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/cc763125-04fe-4a8d-9940-625c0f25cc50n%40googlegroups.com.
