[gollvm] compiling error of libgo/runtime/aeshash.c on ARM

[Xiangdong Ji]

Hello,

I am trying to build gollvm on ARM with a few experimental changes, looks like some ARM Neon intrinsics in

libgo/runtime/aeshash.c are not supported by GCC 7/8, wondering if it could be solved by any additional compile

options, or should the latest gcc-9 or clang be used?

clang could compile this single file without errors but I haven't made it pass the CMake test, and seems

that building gcc-9 on my platform will take much longer time than expected, it would be of great help if the issue

could be addressed with gcc-7/8. 

Any comment is highly appreciated!

------ errors issued by gcc

aeshash.c:733:11: error: incompatible types when assigning to type ‘uint8x16x3_t {aka struct uint8x16x3_t}’ from type ‘int’

   avseed3 = vld1q_u8_x3((uint8*)(pseed + 3));

           ^

aeshash.c:754:10: error: incompatible types when assigning to type ‘uint8x16x2_t {aka struct uint8x16x2_t}’ from type ‘int’

   avval2 = vld1q_u8_x2((uint8*)(p));

          ^

It turns out:

    gcc-7.4.0 doesn't recognize both "vld1q_u8_x3" and "vld1q_u8_x2" 

    gcc-8.3.0 doesn't recognize "vld1q_u8_x3"

[Ian Lance Taylor]

On Mon, Jul 15, 2019 at 7:39 AM Xiangdong Ji <xiangd...@gmail.com> wrote:
>
> I am trying to build gollvm on ARM with a few experimental changes, looks like some ARM Neon intrinsics in
> libgo/runtime/aeshash.c are not supported by GCC 7/8, wondering if it could be solved by any additional compile
> options, or should the latest gcc-9 or clang be used?

The arm64 support in aeshash.c was added in GCC 9. In general there
is no expectation that the files in GCC 9 can be compiled by earlier
versions of GCC. Many times it will work, but not always, and this
may be a case where it fails (I haven't checked). It's not feasible
for us to ensure that files distributed with GCC 9 can be compiled by
earlier versions of GCC.

In any case, if your goal is to build GoLLVM, then you should be
compiling this file with clang. And it sounds like you can do that.
So there doesn't seem to be much reason to compile it with GCC. I
understand that you are having trouble building GoLLVM, but it's not
clear to me why building this file with GCC rather than clang will
help with that.

Ian

[xiangd...@gmail.com]

Thanks a lot, Ian, I can build it with clang now with a few minor changes. 
 
On Tuesday, July 16, 2019 at 5:40:24 AM UTC+8, Ian Lance Taylor wrote:

[xiangd...@gmail.com]

Hi Ian,

Could you please share some code pointers or documents about how 'go' functions calling 'c' functions is implemented,

I'm looking into the following function at gofrontend/libgo/go/bytes/bytes.go:102, where c-function IndexByte in bytealg.c/bytealg.c:90

is called but with wrong argument bindings, the issue is sort of expected as a bunch of changes on arm are not in place now.

Thanks a lot. 

    

// IndexByte returns the index of the first instance of c in b, or -1 if c is not present in b.

func IndexByte(b []byte, c byte) int {

return bytealg.IndexByte(b, c)

}

On Tuesday, July 16, 2019 at 5:40:24 AM UTC+8, Ian Lance Taylor wrote:

[Than McIntosh]

Hi,

Just to make sure I understand the context for the question -- this is a gollvm-compiled program that you are talking about, not something compiled with the main Go compiler?

If so, then there isn't anything special happening when Go calls into C, both will share the same ABI / calling convention. 

Also wanted to make sure you are aware that for Gollvm to work on Arm, the compiler has to implement the ARM C ABI properly (which at the moment is not implemented). See this thread for context:

https://groups.google.com/d/msg/golang-nuts/Tf0BOTtEpOs/0Wdol4pMDgAJ

Cheers, Than

--
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/954aea89-c6ad-422a-9599-47336f0bec53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[xiangd...@gmail.com]

Hi Than,

Thank you for the prompt reply, my apologies for not being descriptive of the context. 

Yes, it's a gollvm-compiled program on arm and we just started investigating the ABI part, I'm wondering if any documents about go's internals are available to help understand it and related areas more deeply. 

On Wednesday, July 17, 2019 at 12:12:54 AM UTC+8, Than McIntosh wrote:

Hi,

Just to make sure I understand the context for the question -- this is a gollvm-compiled program that you are talking about, not something compiled with the main Go compiler?

If so, then there isn't anything special happening when Go calls into C, both will share the same ABI / calling convention. 

Also wanted to make sure you are aware that for Gollvm to work on Arm, the compiler has to implement the ARM C ABI properly (which at the moment is not implemented). See this thread for context:

https://groups.google.com/d/msg/golang-nuts/Tf0BOTtEpOs/0Wdol4pMDgAJ

Cheers, Than

To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

[Ian Lance Taylor]

On Tue, Jul 16, 2019 at 9:35 AM xiangd...@gmail.com
<xiangd...@gmail.com> wrote:
>
> Thank you for the prompt reply, my apologies for not being descriptive of the context.
> Yes, it's a gollvm-compiled program on arm and we just started investigating the ABI part, I'm wondering if any documents about go's internals are available to help understand it and related areas more deeply.

I'm not clear on what kind of documentation you are looking for. As
Than said, GoLLVM and gccgo use the ordinary processor calling
convention.

Perhaps it would help to read
https://gcc.gnu.org/onlinedocs/gccgo/C-Interoperability.html#C-Interoperability
.

Ian