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.
