CC @thanm @cherrymui

I'm not clear: do you have patches to send? Thanks.

@ianlancetaylor , I am on my way to find what to patch. Would require some verification from the committers.

• multilib related function getOSLibDir(...):
  https://go.googlesource.com/gollvm/+/refs/heads/master/driver/LinuxToolChain.cpp#34
  I am glad for https://go.googlesource.com/gollvm/+/refs/heads/master/driver/LinuxToolChain.cpp#41 - but I see potential source for a bug, in case of i686 at https://go.googlesource.com/gollvm/+/refs/heads/master/driver/LinuxToolChain.cpp#43
  .

• Linux::getDynamicLinker(...):
  https://go.googlesource.com/gollvm/+/refs/heads/master/driver/LinuxToolChain.cpp#108 thew https://go.googlesource.com/gollvm/+/refs/heads/master/driver/LinuxToolChain.cpp#110 ;
  https://go.googlesource.com/gollvm/+/refs/heads/master/driver/LinuxToolChain.cpp#123 - OK, relative.
  A potential source for a bug, in case of i686: it is pretty naive to rely on linker/loader naming conventions. Straightforward case (for the switch) should be defined, to separate from i386 related scenario.

• Support for Windows 10 could be offered by adding WindowsToolChain.h and WindowsToolChain.cpp (but names could differ - I am not insisting on specific ones and not presenting Microsoft here). i386 and i686 architectures should be presented separately.

• Libffi related cmake/modules/LibffiUtils.cmake contains some arch related options/switches - but that seem to a problem of an external project repo:
  https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/LibffiUtils.cmake#6 assumes that https://github.com/libffi/libffi/blob/master/src/x86/win64_intel.S could the route for i686 related scenario.
  As for i386 - there is no concrete switch (that could allow to trace that) after https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/LibffiUtils.cmake#10.
  So it should be added here.
  https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/LibffiUtils.cmake#33 requires more comments/some elaborations.
  Some continuation of previously mentioned issues are obserable at https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/LibffiUtils.cmake#50 , continued pretty speculatively at https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/LibffiUtils.cmake#52 and there are no separated scenario for i386 and i686, at https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/LibffiUtils.cmake#54 (assuming that there should be similar blocks, for 32bit hardware and cross-compilation of 32bit-on-64bit machine).
  . Absolutely unacceptable/unserious and untracable scenario at https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/LibffiUtils.cmake#64 - it is a week strategy to distiguish whether we are compiling on 32bit hardware (for 32bit hardware, of course) versus compiling 32bit app on 64bit hardware. The last scenario should be clearly separated, to allow traceability.
  https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/LibffiUtils.cmake#91 - pretty much the same (as above).

In driver/GollvmOptions.td:
https://go.googlesource.com/gollvm/+/refs/heads/master/driver/GollvmOptions.td?autodive=0%2F#350 and https://go.googlesource.com/gollvm/+/refs/heads/master/driver/GollvmOptions.td?autodive=0%2F#352 appear to be pretty related.
I am not clearly understanding the purpose of mx32 flag. Is it for i686? Or that is something for pointing on a scenario for compiling 32bit binary/libraries on 64bit machine?
Some comments would be much appreciated at https://go.googlesource.com/gollvm/+/refs/heads/master/driver/GollvmOptions.td?autodive=0%2F#355.

In cmake/modules/LibbacktraceUtils.cmake :
https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/LibbacktraceUtils.cmake?autodive=0%2F%2F#8 has no options for Intel's i686 and i386 CPUs.
Regarding
message(SEND_ERROR "Libbacktrace config setup not implemented for ${goarch}"
on https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/LibbacktraceUtils.cmake?autodive=0%2F%2F#15 : there is no message for end-users regarding whether this should be an issue of gollvm project or that is the responsibility of libbacktrace project.
@ianlancetaylor , please help to resolve this.

In cmake/modules/GoVars.cmake :
https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/GoVars.cmake?autodive=0%2F%2F#8 has no hardcode scenarios for i686 and i386 architectures.
Line https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/GoVars.cmake?autodive=0%2F%2F#15 should have both llarch and goarch logged.
Similar situation around https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/GoVars.cmake?autodive=0%2F%2F#24 .
Week strategy to rely on linker's/loader's naming convention, at https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/GoVars.cmake?autodive=0%2F%2F#31.
Line https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/GoVars.cmake?autodive=0%2F%2F#29 should have underlying comments on what/where tracing is available, since that is an external library - so a tryout on loading a specific one (that should be trackable thew stdout) would be observable.
No blocks of code are dealing with i686 and i386 - a good reason to patch here.

In cmake/modules/AutoGenGo.cmake :
Two elseif blocks (i386 and i686 related ones) should added somewhere after https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/AutoGenGo.cmake?autodive=0%2F#63.
More democracy should be reflected at https://go.googlesource.com/gollvm/+/refs/heads/master/cmake/modules/AutoGenGo.cmake?autodive=0%2F#65 and, eventually, amd64 and aarch64 wouldn't be the only reflected architectures.
Some status and URLs for issues, related to other architectures, could be messaged here.

• In driver/CompileGo.cpp :

Function CompileGoImpl::setCConv() , at https://go.googlesource.com/gollvm/+/refs/heads/master/driver/CompileGo.cpp#816 should have switches for i386 and i686 related scenarios.
I am unsure how CallingConv::... should look like - I am unsure if I can find where their definitions are defined (headers).
Is it coming from LLVM's libraries?

• In driver/Driver.cpp :
  There should be some de-facto separated sub-folders for i386 and i686 in the directory/folder hierarchy (where?), to satisfy definitions at https://go.googlesource.com/gollvm/+/refs/heads/master/driver/Driver.cpp#67.
  As for
  // NOTE: set aarch64's lib dir to "lib64" temporarily, until necessary // change is made to cmake module files
• that should be changed ASAP and I do not see anything obvious in consider one of the arch., having 64 bit instructions, as something obviously "default". i386 and i686 should be covered, among those options.

• In Libgo/CMakeLists.txt :

not clear if there is something that should be hardcode, specifically for scenarios of i386 and i686 CPUs (respectively), as it is done for x86_64 - at https://go.googlesource.com/gollvm/+/refs/heads/master/libgo/CMakeLists.txt#447.
Since the status of gollvm project/feature coverage for Golang's runtime considers documented per-arch. instructions sets - those should be documented and hardcoded, as done at https://go.googlesource.com/gollvm/+/refs/heads/master/libgo/CMakeLists.txt#483.

• In driver/ArchCpusAttrs.h :

Add attributes for i38 and i686 architectures, respectively.

@aregm , @fexolm - feel free to share your vision.
Thanks in advance

@thanm, why can't your project integrate https://github.com/intel-go/cpuid ?

@linux4life798 , @bramp - please follow up

Lots of comments and observations here, sounds like the next step is to write some patches.

@thanm , I was trying to say that a cooperated review is required (a reason for a community call?).
Perhaps during Go engineering community calls or LLVM user group community calls.
I guess a PR is required/an agenda.
I am investigating what is required on Windows and Linux (i386) - and Microsoft's vision of Windows port (X86;X86_64) would help to support it natively (to mingw or cygwin).

Closing this in favor of #42440