Than, I could perform "git diff" and provide the generated file. I could also compress & share the build folder. What else would be required?
Ivan On Wednesday, January 6, 2021 at 5:07:06 PM UTC+2 th...@google.com wrote: > > It would be helpful if you could put up a CL that includes all of the > changes you're testing -- at this point do you have any modifications to > driver/ArchCpusAttrs.h ? > > Thanks > > > > On Wed, Jan 6, 2021 at 10:00 AM Ivan Serdyuk <local.tou...@gmail.com> > wrote: > >> 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...@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 >> >> <https://groups.google.com/d/msgid/golang-nuts/cc763125-04fe-4a8d-9940-625c0f25cc50n%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/67c15826-5ed2-40ca-b284-6ff471fb6584n%40googlegroups.com.
