>
> It seems annoying to force
> everyone to write interface{} all the time when it is normally not
> needed.
>
I agree, omitting interface{} should not cause much trouble to the parser.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To
I have been building Gollvm in a container, I can build it successfully no
matter on amd64 and arm64. But the ld.gold error message really exists on
both platforms.
在 2020年5月26日星期二 UTC+8上午10:14:43，Yuan Ting写道：
>
> I tried to build gollvm in a docker container (the image is based on
> ubuntu
Does anyone know this? Or this is an unimplemented feature ?
在 2020年5月19日星期二 UTC+8下午7:49:53，eric fang写道：
>
> How to generate the cfg of the following Replace method ? I used this
> command "GOSSAFUNC=Replace:* go tool compile main.go" but it doesn't work.
> Thanks.
>
How to generate the cfg of the following Replace method ? I used this
command "GOSSAFUNC=Replace:* go tool compile main.go" but it doesn't work.
Thanks.
package main
type byteReplacer [256]byte
func (r *byteReplacer) Replace(s string) string {
var buf []byte // lazily allocated
s at
> https://go-review.googlesource.com/c/gollvm/+/232497 if you want to look
> it over. Not quite done yet, still a few things to wrap up.
>
> Cheers, Than
>
>
>
> On Wed, May 6, 2020 at 5:46 AM eric fang >
> wrote:
>
> This seems to be the synchronization problem of
This seems to be the synchronization problem of gollvm and llvm, I am
fixing it today, if you have not done it, I can help.
在 2020年5月5日星期二 UTC+8下午8:30:14，Than McIntosh写道：
>
> OK, thanks for that. I will investigate, this looks unrelated to the
> previous problem. Stay tuned.
>
> Cheers, Than
>
>
> The way that I had imagined this working was that either each
> testpoint has a loop over the various supported ABI flavors (and checks
> output for each flavor)
>
Yes, for those common test cases, I just did this.
> or we have separate testpoints for each ABI
> (e.g.
Hi Than,
I'm porting the unit test cases of x86 to arm64. As the difference between
x86 abi and arm64 abi, for the same go code snippet, the generated llvm IRs
maybe different.
How do you get the correct IR result of a unit test? Such as unit
test TEST(BackendCABIOracleTests, RecursiveCall1).
Hi Ian, go-delve for arm64 (https://github.com/go-delve/delve/issues/1715)
also encountered this problem, I want to fix this problem.
unix.PtraceGetRegsArm64 may be not work on Linux arm64 since version
2.6.34, because PTRACE_GETREGS has been replaced with PTRACE_GETREGSET, no
longer support
Hi Than, I think here should be the right place to handle this case, and I
have corrected the code. I should use BlockLIRBuilder instead of
BinstructionLIRBuilder. I have implemented a prototype of the code and at
present everything is normal. Next I will start writing some unit test
cases.
Hi Than,
I got another question for you. For indirect parameters, arm-aapcs abi
requires to do a copy of the parameter on stack, and then pass the address
of the copied parameter to callee. I tried to do a memcpy of the indirect
parameter in function Llvm_backend::genCallMarshallArgs, but
Hi Than,
I got it, thanks for your detailed explanation. And I'm also thinking about
how to write test cases, the cabi-testgen project would be a great help, I
will keep you informed if there are other questions or updates, thank you.
--
You received this message because you are subscribed to
Hi Than,
I'm trying to implement the abi part for arm64, and got two questions for
you:
1, function CABIOracle::canPassDirectly in
gollvm/bridge/go-llvm-cabi-oracle.cpp, I'm not quite understand the first
if statement:
if (regsInt + regsSSE == 1)
return true;
Why not consider whether
Hi Than,
Thanks for your help, "check-gollvm" is exactly what I'm looking for. But
on x86-64, there are two test failures, as the log is very long, we just
put some key info here.
[152/189] Checking Go package go/internal/gccgoimporter
FAILED:
Hi,
Another three questions about test and benchmark.
1, Currently I can build all unit test executable files by "% ninja
GoBackendUnitTests", but in order to run all tests, I have to run the test
executable files under all the directories. Do we have a single command to
perform all unit
o look at only life
> heap pointers during scanning.
>
> There are some other small differences between Gollvm and GC garbage
> collection (notably the representation of the global roots list) but in
> general they are using pretty much the same collector.
>
> Thanks, Than
Hi Than, when I read the code, I found enable_gc_ is false by default, the
description of option "-enable-gc=" is "Enable stack map
generation". I guess gollvm should have implemented garbage collection. My
question are:
1, what kind of gc does gollvm currently implement, and what is the
Hi Than,
Thanks for your guide, this certainly helps. I don't have any specific
questions at the moment. Thanks again.
--
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
>
> >>I'll write down a more specific list of tips and pointers to the code
> later today; stay tuned.
>
Hi Than, I'm also very interested in this work and look forward to your
update.
I'm reading the gollvm code, but I haven't figured out the relationship
between the various modules
19 matches
Mail list logo
