You can of course run capture-fcn-attributes with an explicit set of triples, e.g.
$ ./capture-fcn-attributes -o ../driver/ArchCpusAttrs.h -triples i686-pc-linux-gnu which will get you off the ground... but you would not want to check in the resulting header. The values in ArchCpusAttrs.h have to cover all supported targets. Than On Wed, Jan 6, 2021 at 4:31 PM Ivan Serdyuk <local.tourist.k...@gmail.com> wrote: > My current scenario assumes that I have compiled for x86 targets, to run > Clang on an x86 machine. What should be done if it is not assumed to > involve any other back-ends, during the build? > > > On Wed, Jan 6, 2021 at 10:27 PM Than McIntosh <th...@google.com> wrote: > >> Right, that would be expected. The easiest thing to do is make sure >> that you're running cmake in your build area with >> >> -DLLVM_TARGETS_TO_BUILD="all" >> >> then you can build "llc" and "clang" , then update your path so that the >> freshly built llc/clang are picked up first. Once you have that set up, it >> should take care of the problem running "llc" from capture-fcn-attributes. >> >> Than >> >> >> On Wed, Jan 6, 2021 at 3:14 PM Ivan Serdyuk <local.tourist.k...@gmail.com> >> wrote: >> >>> I think a caught an error: >>> >>> $ ./capture-fcn-attributes >>>> llc run failed: llc: error: : error: unable to get target for >>>> 'aarch64-unknown-linux-gnu', see --version and --triple. >>>> >>>> capture-fcn-attributes: err = exit status 1 >>>> >>> >>> . Hence that I didn't compile Aarch64 back-end, for LLVM: >>> >>> $ llc --version >>>> LLVM (http://llvm.org/): >>>> LLVM version 12.0.0git >>>> Optimized build. >>>> Default target: i686-pc-linux-gnu >>>> Host CPU: yonah >>>> >>>> Registered Targets: >>>> x86 - 32-bit X86: Pentium-Pro and above >>>> x86-64 - 64-bit X86: EM64T and AMD64 >>>> >>> . So this would not run out-of-the-box. >>> >>> >>> >>> On Wed, Jan 6, 2021 at 8:21 PM Than McIntosh <th...@google.com> wrote: >>> >>>> Thanks. The error you're seeing >>>> >>>> "unable to determine target CPU features for target i686-pc-linux-gnu" >>>> >>>> looks as though it's because i686-pc-linux-gnu isn't listed as a target >>>> in >>>> driver/ArchCpusAttrs.h. >>>> >>>> From the root of your repo, try >>>> >>>> $ cd tools >>>> $ go build capture-fcn-attributes.go >>>> $ ./capture-fcn-attributes -o ../driver/ArchCpusAttrs.h >>>> >>>> and then give the gollvm build another try. >>>> >>>> Thanks, Than >>>> >>>> On Wed, Jan 6, 2021 at 12:53 PM Ivan Serdyuk < >>>> local.tourist.k...@gmail.com> wrote: >>>> >>>>> Here you go: >>>>> >>>>> ~/Desktop/workarea/llvm-project/llvm/tools/gollvm$ git diff >>>>> diff --git a/cmake/modules/AutoGenGo.cmake >>>>> b/cmake/modules/AutoGenGo.cmake >>>>> index 3e3ab83..097a2ad 100644 >>>>> --- a/cmake/modules/AutoGenGo.cmake >>>>> +++ b/cmake/modules/AutoGenGo.cmake >>>>> @@ -51,6 +51,17 @@ function(mkversion goos goarch outfile bindir >>>>> srcroot scriptroot) >>>>> set(pcquantum "1") >>>>> set(int64align "8") >>>>> set(minframesize 0) >>>>> + elseif( ${goarch} STREQUAL "386") >>>>> + # Simply picking up one typical setting >>>>> + # Align with current sets in gofrontend/libgo/goarch.sh >>>>> + set(archfamily "I386") >>>>> + set(bigendian "false") >>>>> + set(cachelinesize "64") >>>>> + set(physpagesize "4096") >>>>> + set(pcquantum "1") >>>>> + set(int64align "4") >>>>> + set(minframesize 4) >>>>> + set(ptrsize 4) >>>>> elseif( ${goarch} STREQUAL "arm64") >>>>> # Simply picking up one typical setting >>>>> # Align with current sets in gofrontend/libgo/goarch.sh >>>>> diff --git a/cmake/modules/GoVars.cmake b/cmake/modules/GoVars.cmake >>>>> index ec6f6b2..0cea38a 100644 >>>>> --- a/cmake/modules/GoVars.cmake >>>>> +++ b/cmake/modules/GoVars.cmake >>>>> @@ -8,6 +8,9 @@ list(GET lht_components 2 goos) >>>>> # LLVM's "x86_64" is the same as Go's "amd64". >>>>> if( ${llarch} STREQUAL "x86_64" ) >>>>> set(goarch "amd64") >>>>> +# For i386/i686 >>>>> +elseif( ${llarch} STREQUAL "i686" ) >>>>> + set(goarch "386") >>>>> # LLVM's "aarch64" is the same as Go's "arm64". >>>>> elseif( ${llarch} STREQUAL "aarch64" ) >>>>> set(goarch "arm64") >>>>> @@ -23,6 +26,10 @@ set(allgoos "aix" "android" "darwin" "dragonfly" >>>>> "freebsd" "irix" "linux" "netbs >>>>> # Set library suffix based on target triple >>>>> if( ${llarch} STREQUAL "x86_64" ) >>>>> set(library_suffix "64") >>>>> +elseif( ${llarch} STREQUAL "i686" ) >>>>> +# Driver::installedLibDir honors ./lib only, on Ubuntu 16 >>>>> +# But we can stick for ./lib32 (along with those in AddGollvm.cmake) >>>>> + set(library_suffix "32") >>>>> elseif( ${llarch} STREQUAL "aarch64" ) >>>>> # Driver::installedLibDir honors ./lib64 only >>>>> # Future change needed (along with those in AddGollvm.cmake) >>>>> diff --git a/cmake/modules/LibbacktraceUtils.cmake >>>>> b/cmake/modules/LibbacktraceUtils.cmake >>>>> index dc54f18..42287a9 100644 >>>>> --- a/cmake/modules/LibbacktraceUtils.cmake >>>>> +++ b/cmake/modules/LibbacktraceUtils.cmake >>>>> @@ -8,6 +8,9 @@ function(setup_libbacktrace) >>>>> if( ${goarch} STREQUAL "amd64") >>>>> set(BACKTRACE_ELF_SIZE 64) >>>>> set(HAVE_GETIPINFO 1) >>>>> + elseif( ${goarch} STREQUAL "386") >>>>> + set(BACKTRACE_ELF_SIZE 32) >>>>> + set(HAVE_GETIPINFO 1) >>>>> elseif( ${goarch} STREQUAL "arm64") >>>>> set(BACKTRACE_ELF_SIZE 64) >>>>> set(HAVE_GETIPINFO 1) >>>>> diff --git a/cmake/modules/LibffiUtils.cmake >>>>> b/cmake/modules/LibffiUtils.cmake >>>>> index b3fa697..fb34c36 100644 >>>>> --- a/cmake/modules/LibffiUtils.cmake >>>>> --- a/cmake/modules/LibffiUtils.cmake >>>>> +++ b/cmake/modules/LibffiUtils.cmake >>>>> @@ -9,6 +9,8 @@ function(setup_libffi libffi_srcroot) >>>>> set(arch_dir "aarch64") >>>>> elseif(${llarch} STREQUAL "x86_64") >>>>> set(arch_dir "x86") >>>>> + elseif(${llarch} STREQUAL "i686") >>>>> + set(arch_dir "x86") >>>>> else() >>>>> message(SEND_ERROR "Arch ${llarch} not yet supported") >>>>> endif() >>>>> diff --git a/driver/Driver.cpp b/driver/Driver.cpp >>>>> index 8debbab..aa83fb1 100644 >>>>> --- a/driver/Driver.cpp >>>>> +++ b/driver/Driver.cpp >>>>> @@ -76,7 +76,7 @@ std::string Driver::installedLibDir() >>>>> llvm::sys::path::append(ldir, "../lib64"); >>>>> break; >>>>> default: >>>>> - llvm::sys::path::append(ldir, "../lib64"); >>>>> + llvm::sys::path::append(ldir, "../lib"); >>>>> break; >>>>> } >>>>> : >>>>> --- a/cmake/modules/LibffiUtils.cmake >>>>> +++ b/cmake/modules/LibffiUtils.cmake >>>>> @@ -9,6 +9,8 @@ function(setup_libffi libffi_srcroot) >>>>> set(arch_dir "aarch64") >>>>> elseif(${llarch} STREQUAL "x86_64") >>>>> set(arch_dir "x86") >>>>> + elseif(${llarch} STREQUAL "i686") >>>>> + set(arch_dir "x86") >>>>> else() >>>>> message(SEND_ERROR "Arch ${llarch} not yet supported") >>>>> endif() >>>>> diff --git a/driver/Driver.cpp b/driver/Driver.cpp >>>>> index 8debbab..aa83fb1 100644 >>>>> --- a/driver/Driver.cpp >>>>> +++ b/driver/Driver.cpp >>>>> @@ -76,7 +76,7 @@ std::string Driver::installedLibDir() >>>>> llvm::sys::path::append(ldir, "../lib64"); >>>>> break; >>>>> default: >>>>> - llvm::sys::path::append(ldir, "../lib64"); >>>>> + llvm::sys::path::append(ldir, "../lib"); >>>>> break; >>>>> } >>>>> return std::string(ldir.str()); >>>>> >>>>> and >>>>> >>>>> $ git log -1 >>>>> commit 850255c5cd7f9df79a148d537fd395089b7caf29 (HEAD -> master, >>>>> origin/master, origin/HEAD) >>>>> Author: Ivan Serdyuk <local.tourist.k...@gmail.com> >>>>> Date: Fri Dec 4 17:14:00 2020 +0200 >>>>> >>>>> gollvm: Updating README.md, to elevate the min. required version >>>>> of Clang compiler >>>>> >>>>> Too many issues with Clang 9 - so let's assume Clang 10+ >>>>> >>>>> Change-Id: Icf1a74148878b07fd941e5d525ac7e0c7f6bfdaf >>>>> Reviewed-on: https://go-review.googlesource.com/c/gollvm/+/275473 >>>>> Reviewed-by: Than McIntosh <th...@google.com> >>>>> Trust: Ian Lance Taylor <i...@golang.org> >>>>> >>>>> On Wednesday, January 6, 2021 at 5:34:17 PM UTC+2 th...@google.com >>>>> wrote: >>>>> >>>>>> Diff is fine. No need for the entire folder. >>>>>> Than >>>>>> >>>>>> >>>>>> On Wed, Jan 6, 2021 at 10:18 AM Ivan Serdyuk <local.tou...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> 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...@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 >>>>>>> <https://groups.google.com/d/msgid/golang-nuts/67c15826-5ed2-40ca-b284-6ff471fb6584n%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/399b00c6-8a6c-46aa-8397-b7d01cd85e44n%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/golang-nuts/399b00c6-8a6c-46aa-8397-b7d01cd85e44n%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/CA%2BUr55HrOir9D63x%3DNggrm%2B%3DUdPRNbas4J_-kGX3zh%3D1UiAVNQ%40mail.gmail.com.
