-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gollvm: supporting i386/i686 builds (Intel) #42440
Comments
I am attaching the specification, System V Application Binary Interface |
My first patch, submitted for a review is https://go-review.googlesource.com/c/gollvm/+/270219 .
|
My next patch would cover driver/ArchCpusAttrs.h https://go-review.googlesource.com/c/gollvm/+/271457 Since it is required to perform pre-checks of supported CPU features (in my case - I have a relic Intel Celeron M440), which is resolved by Clang (common code for any LLVM related projects, for these checks - so both llvm-goc and pre-installed Clang would both act similar, on a specific hardware) - I used the following tool:
. |
I missed a file, where library path should be handled: https://go.googlesource.com/gollvm/+/refs/heads/master/driver/Driver.cpp#70 |
@thanm, @cherrymui: I don't understand why CABIOracle contains "Oracle" in it's naming. Attaching some diagrams, as a rude summary: |
I see some adoptions of EightByteInfo::determineABITypesForLLVM's calling convention function. Looks like EightByteInfo class has a constructor, which initializes private variable typeManager_ with the same of the second passed argument (of type *TypeManager). |
@advancedwebdeveloper "oracle" happens to be the name of a company but it is also an English word. It also has a well established meaning specific to computer programming: https://en.wikipedia.org/wiki/Oracle_machine . |
Ian is correct. "Oracle" is being used in the non-commercial sense (as in "Oracle of Delphi"), e.g. some entity that you ask questions of. |
Referencing http://llvm.org/docs/LangRef.html#parameter-attributes - specific considerations would be added later |
Reminding about unresolved issue #42975 |
You are referencing System V x86_64 ABI spec. , on https://go.googlesource.com/gollvm/+/refs/heads/master/bridge/go-llvm-cabi-oracle.cpp#61 .
In the same time - I am able to extract the following statements, from i386 ABI spec. http://www.sco.com/developers/devspecs/abi386-4.pdf#page=29 :
Unsure if the following contains any useful statements, for elaborating this:
|
I am able to extract the following, from i386 ABI spec., on http://www.sco.com/developers/devspecs/abi386-4.pdf#page=36 :
And by taking
into an account, on http://www.sco.com/developers/devspecs/abi386-4.pdf#page=27 - that would be 32/8=4 bytes |
So if it differs from what happens on x86_64 - the struct EightByteRegion should not be compiled on i686. Probably that i686 oriented struct should contain such functions:
|
Probably related to #42440 (comment) : we could provide such functions: CABIOracleC::CABIOracleC(TypeManager *typeManager): CABIOracleArgumentAnalyzer(typeManager) ; |
Stack alignment on 32-bit x86 has become quite complex. Search for "stack" in https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/x86-Options.html#x86-Options. |
@marmolejo , please elaborate regarding 32bit soft-CPU implementation and consideration for stack alignments. |
@JonChesterfield , could you elaborate regarding relic 32bit AMD's CPUs? |
@tve , I remember that you tried to build Go applications for a retired/relic VIA's CPU (eons ago). |
@kcadieux , @GreatKeeper : could you elaborate about MSVC's stack alignment, when compiling (and linking, by using Microsoft's linker) for 32bit Windows 10 (i686) ? |
Citation from https://reviews.llvm.org/D60748 :
I didn't new about about that, btw. @pcordes , found your old post here . |
Currently, Clang always aligns to 4 bytes on i386 standard calling conversion. This is not strictly following psABI/gcc. Chen had a new patch https://reviews.llvm.org/D78564 to fix the problem after D60748 abandoned. But it hasn't been accepted. |
D78564 is trying to fix the wrong alignment when the parameters are unnamed parameters(Only for __m128, __m256 and __m512).
gcc will align to 64 byte but clang will align to 4 byte. For D78564, when the parameter is unnamed, the callee will always assume that the alignment of the unnamed parameter is align to 4 byte. For common struct there is no problem. But for __m128/256/512, caller will align these parameters to 16/32/64 bytes, the callee will get wrong result. |
@thanm, could you provide an extended explanation of 16 bytes sizing? https://go.googlesource.com/gollvm/+/refs/heads/master/bridge/go-llvm-cabi-oracle.cpp#156 Which of those are ABI specific (System V x86_64, not related to the current i686 issue)? Which are specific to https://tour.golang.org/basics/11 (int16)? Specific to LLVM itself? |
Mailing list is a better place for questions of this sort. Happy to respond on golang-dev. |
I am creating this issue for a future patch (and others should be expected, for the same purpose), observable on/threw Gerrit.
It would be referenced (a bit) later.
This is about compiling & running 32bit userspace Go applications on (under?) 32bit CPU/hardware/OS kernel (system-on-board).
Something for 32bit AMD's CPUs would be a good cause for a separate Github issue.
This is not covering the following (corresponding options/use cases should be covered within separate Github issues):
.
This issue covers few OS-compiler combinations (at once).
I will update this summary once there would be a demand to extend the scope.
GCC, Clang compilers on Linux.
MSVC compiler on Windows.
Not sure what to assume on MacOS (I heard that they have a hybrid 32bit/64bit kernel - but I am not an expert).
GCC, Clang on FreeBSD.
The text was updated successfully, but these errors were encountered: