[go-nuts] Re: SSA-able and canSSA meaning in Go compiler's SSA backend?

[howardcshaw]

Read this wiki page to understand what the goal is:
https://en.wikipedia.org/wiki/Static_single_assignment_form

Basically, SSA-form allows certain optimizations that are harder without 
it, but SSA is also itself hard to apply. SSA examples are often posed in 
the form of simple variables, but real code has structs and arrays and maps 
and slices. So they mark things that are worth the effort of applying SSA 
to and things they've (the compiler writers, that is) have decided are not 
worth of pushing down to an SSA form.

So, the special purpose it serves is to enable a class of optimizations. 
And the difference from non-SSA-able values is simply one of cost/benefit. 
Non-SSA-able values are actually those where implementing SSA was deemed 
either not possible or too expensive (either in terms of time, or code, or 
just the compiler author's brainspace).

-- 
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/24f48b18-3bd8-4796-bfac-6deb965da99b%40googlegroups.com.

[go-nuts] Re: SSA-able and canSSA meaning in Go compiler's SSA backend?

[howardcshaw]

Read this wiki page to understand what the goal is:
https://en.wikipedia.org/wiki/Static_single_assignment_form

Basically, SSA-form allows certain optimizations that are harder without 
it, but SSA is also itself hard to apply. SSA examples are often posed in 
the form of simple variables, but real code has structs and arrays and maps 
and slices. So they mark things that are worth the effort of applying SSA 
to and things they've (the compiler writers, that is) have decided are not 
worth of pushing down to an SSA form.

So, the special purpose it serves is to enable a class of optimizations. 
And the difference from non-SSA-able values is simply one of cost/benefit. 
Non-SSA-able values are actually those where implementing SSA was deemed 
either not possible or too expensive (either in terms of time, or code, or 
just the compiler author's brainspace).

Here is a link to a talk from a Go developer about adding SSA to the 
compiler:
https://about.sourcegraph.com/go/generating-better-machine-code-with-ssa

-- 
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/d9505d32-c90f-4218-8d51-4cc57ba91745%40googlegroups.com.

[go-nuts] Re: SSA-able and canSSA meaning in Go compiler's SSA backend?

[howardcshaw]

Read this wiki page to understand what the goal is:
https://en.wikipedia.org/wiki/Static_single_assignment_form

Basically, SSA-form allows certain optimizations that are harder without 
it, but SSA is also itself hard to apply. SSA examples are often posed in 
the form of simple variables, but real code has structs and arrays and maps 
and slices. So they mark things that are worth the effort of applying SSA 
to and things they've (the compiler writers, that is) have decided are not 
worth of pushing down to an SSA form.

So, the special purpose it serves is to enable a class of optimizations. 
And the difference from non-SSA-able values is simply one of cost/benefit. 
Non-SSA-able values are actually those where implementing SSA was deemed 
either not possible or too expensive (either in terms of time, or code, or 
just the compiler author's brainspace).

Here is a link to a talk from a Go developer about adding SSA to the 
compiler:
https://about.sourcegraph.com/go/generating-better-machine-code-with-ssa

(P.S. if this ends up posting multiple times, I apologize. It has told me 
there was an error communicating with the server twice now.)

-- 
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/6e1cc086-31ca-4dd8-bce1-3e0cdf14af5a%40googlegroups.com.

[go-nuts] Re: SSA-able and canSSA meaning in Go compiler's SSA backend?

[Agniva De Sarker]

> Here is a link to a talk from a Go developer about adding SSA to the 
compiler

That Go developer is the one who answered OP's question :)

On Thursday, 19 September 2019 17:55:33 UTC+5:30, howar...@gmail.com wrote:
>
> Read this wiki page to understand what the goal is:
> https://en.wikipedia.org/wiki/Static_single_assignment_form
>
> Basically, SSA-form allows certain optimizations that are harder without 
> it, but SSA is also itself hard to apply. SSA examples are often posed in 
> the form of simple variables, but real code has structs and arrays and maps 
> and slices. So they mark things that are worth the effort of applying SSA 
> to and things they've (the compiler writers, that is) have decided are not 
> worth of pushing down to an SSA form.
>
> So, the special purpose it serves is to enable a class of optimizations. 
> And the difference from non-SSA-able values is simply one of cost/benefit. 
> Non-SSA-able values are actually those where implementing SSA was deemed 
> either not possible or too expensive (either in terms of time, or code, or 
> just the compiler author's brainspace).
>
> Here is a link to a talk from a Go developer about adding SSA to the 
> compiler:
> https://about.sourcegraph.com/go/generating-better-machine-code-with-ssa
>
> (P.S. if this ends up posting multiple times, I apologize. It has told me 
> there was an error communicating with the server twice now.)
>

-- 
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/2ed33b77-2b01-4395-a163-5f88b91963d3%40googlegroups.com.

[go-nuts] Will the number of OS threads spawned by a golang process never decrease?

[varun . 1312]

Consider a golang program running on a system with GOMAXPROCS value 10. 
Initially OS has spawned 10 threads for execution. Due to blocking system 
calls, OS spawns 30 more threads resulting in 40 OS threads attached to the 
process.After all the blocked system calls return, then will the process 
still be having 40 OS threads? If yes, then can we conclude that the number 
of OS threads mapped to a golang process can grow but never comes down? 

Thanks,
Varun

-- 
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/5d266b57-c991-4915-a7a6-f21c95930d8c%40googlegroups.com.

[go-nuts] Re: go.mod changes on each build, -mod=readonly can never work

[t hepudds]

Hello Russ,

Usually, if you are not modifying your code, I think go.mod should be 
stable across repeated identical invocations of something like 'go build' 
or 'go install'.

I think there were a similar sounding set of bugs fixed for Go 1.13, but 
sounds like you are seeing this with Go 1.13.

A more recent bug was this one, which I think was reported against Go 1.13:

   https://github.com/golang/go/issues/34086

That particular bug has seemingly been fixed in the tip branch. It probably 
is worth trying to see if you can reproduce with that fix in place. A handy 
way to try with the latest from tip / master is:

$ go get golang.org/dl/gotip
$ gotip download 

However, that might not solve it for you. 
 
If you still see the same behavior using 'gotip', then I would suggest 
opening a new bug to make sure one of the people working on cmd/go takes a 
look. It looks like you already have nicely pulled together a public 
reproducer, which is great.

Finally, does 'go mod tidy' seem to be stable in terms of how it leaves 
go.mod?  If so, one approach in the short term might be to run 'go mod 
tidy' to put go.mod into a more stable state (e.g., after running 'go 
install'), but given you seem to be seeing a bug, I'm not sure if that will 
work for you.

Regards,
thepudds

On Wednesday, September 18, 2019 at 7:38:41 PM UTC-4, Russ Selph wrote:
>
> Hi,
>
> I've got a modules problem, and I'm not sure yet whether it's operator 
> error or something worthy of a bug report.  In short, I have a build where 
> go.mod oscillates between two states build by build.  The first build 
> changes it one way, the next build changes it back.  If I try the build 
> with -mod=readonly, it will always fail because every build wants to change 
> go.mod.  This is a real problem for source control.  :-)
>
> I've put together a toy project that demonstrates the problem.  It's based 
> on our real world project, which is pretty large.  This one has no code of 
> any consequence, but is an exact model of the external dependencies.
>
> https://github.com/rselph-tibco/go-unstable-mods
>
> There are two programs and two packages, all contained in two modules, 
> with a sort of twisted interdependency.  But it seems to be the external 
> dependencies that are messing things up.  On subsequent builds of sample1, 
> the go.mod file  does this:
>
> foo.com/me/sample2 v0.0.0-0001010100-
> github.com/coreos/bbolt v1.3.3
> github.com/coreos/etcd v3.3.15+incompatible
> -   github.com/coreos/go-semver v0.3.0 // indirect
> github.com/elazarl/go-bindata-assetfs v1.0.0
> github.com/gorilla/mux v1.7.3
> -   github.com/json-iterator/go v1.1.7 // indirect
> github.com/magiconair/properties v1.8.1
> -   github.com/modern-go/reflect2 v1.0.1 // indirect
> github.com/satori/go.uuid v1.2.0
> golang.org/x/net v0.0.0-20190918130420-a8b05e9114ab
>
> then this:
>
> foo.com/me/sample2 v0.0.0-0001010100-
> github.com/coreos/bbolt v1.3.3
> github.com/coreos/etcd v3.3.15+incompatible
> +   github.com/coreos/go-semver v0.3.0 // indirect
> github.com/elazarl/go-bindata-assetfs v1.0.0
> github.com/gorilla/mux v1.7.3
> +   github.com/json-iterator/go v1.1.7 // indirect
> github.com/magiconair/properties v1.8.1
> +   github.com/modern-go/reflect2 v1.0.1 // indirect
> github.com/satori/go.uuid v1.2.0
> golang.org/x/net v0.0.0-20190918130420-a8b05e9114ab
>
> What's the best way to debug what's going on here?  Does this look like 
> any known problem?  (Search didn't yield anything that looked similar to 
> me.)
>
> You can follow the exact steps and their consequences here: 
> https://github.com/rselph-tibco/go-unstable-mods/commits/master
> All of that was generated by the script at 
> https://github.com/rselph-tibco/go-unstable-mods/blob/master/run.sh
>

-- 
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/63ac661b-7d10-466f-9652-aaf0b2d8f90e%40googlegroups.com.

Re: [go-nuts] Re: go.mod changes on each build, -mod=readonly can never work

['Russ Selph' via golang-nuts]

Thanks for the hints.  I'll try to reproduce from the tip branch before filing 
a bug.

> On Sep 19, 2019, at 09:34, t hepudds  wrote:
> 
> Hello Russ,
> 
> Usually, if you are not modifying your code, I think go.mod should be stable 
> across repeated identical invocations of something like 'go build' or 'go 
> install'.
> 
> I think there were a similar sounding set of bugs fixed for Go 1.13, but 
> sounds like you are seeing this with Go 1.13.
> 
> A more recent bug was this one, which I think was reported against Go 1.13:
> 
>https://github.com/golang/go/issues/34086 
> 
> 
> That particular bug has seemingly been fixed in the tip branch. It probably 
> is worth trying to see if you can reproduce with that fix in place. A handy 
> way to try with the latest from tip / master is:
> 
> $ go get golang.org/dl/gotip 
> $ gotip download 
> 
> However, that might not solve it for you. 
>  
> If you still see the same behavior using 'gotip', then I would suggest 
> opening a new bug to make sure one of the people working on cmd/go takes a 
> look. It looks like you already have nicely pulled together a public 
> reproducer, which is great.
> 
> Finally, does 'go mod tidy' seem to be stable in terms of how it leaves 
> go.mod?  If so, one approach in the short term might be to run 'go mod tidy' 
> to put go.mod into a more stable state (e.g., after running 'go install'), 
> but given you seem to be seeing a bug, I'm not sure if that will work for you.
> 
> Regards,
> thepudds
> 
> On Wednesday, September 18, 2019 at 7:38:41 PM UTC-4, Russ Selph wrote:
> Hi,
> 
> I've got a modules problem, and I'm not sure yet whether it's operator error 
> or something worthy of a bug report.  In short, I have a build where go.mod 
> oscillates between two states build by build.  The first build changes it one 
> way, the next build changes it back.  If I try the build with -mod=readonly, 
> it will always fail because every build wants to change go.mod.  This is a 
> real problem for source control.  :-)
> 
> I've put together a toy project that demonstrates the problem.  It's based on 
> our real world project, which is pretty large.  This one has no code of any 
> consequence, but is an exact model of the external dependencies.
> 
> https://github.com/rselph-tibco/go-unstable-mods 
> 
> 
> There are two programs and two packages, all contained in two modules, with a 
> sort of twisted interdependency.  But it seems to be the external 
> dependencies that are messing things up.  On subsequent builds of sample1, 
> the go.mod file  does this:
> 
> foo.com/me/sample2  
> v0.0.0-0001010100-
> github.com/coreos/bbolt  v1.3.3
> github.com/coreos/etcd  
> v3.3.15+incompatible
> -   github.com/coreos/go-semver  v0.3.0 
> // indirect
> github.com/elazarl/go-bindata-assetfs 
>  v1.0.0
> github.com/gorilla/mux  v1.7.3
> -   github.com/json-iterator/go  v1.1.7 
> // indirect
> github.com/magiconair/properties 
>  v1.8.1
> -   github.com/modern-go/reflect2  
> v1.0.1 // indirect
> github.com/satori/go.uuid  v1.2.0
> golang.org/x/net  
> v0.0.0-20190918130420-a8b05e9114ab
> 
> then this:
> 
> foo.com/me/sample2  
> v0.0.0-0001010100-
> github.com/coreos/bbolt  v1.3.3
> github.com/coreos/etcd  
> v3.3.15+incompatible
> +   github.com/coreos/go-semver  v0.3.0 
> // indirect
> github.com/elazarl/go-bindata-assetfs 
>  v1.0.0
> github.com/gorilla/mux  v1.7.3
> +   github.com/json-iterator/go  v1.1.7 
> // indirect
> github.com/magiconair/properties 
>  v1.8.1
> +   github.com/modern-go/reflect2  
> v1.0.1 // indirect
> github.com/satori/go.uuid  v1.2.0
> golang.org/x/net  
> v0.0.0-20190918130420-a8b05e9114ab
> 
> What's the best way to debug what's going on here?  Does this look like any 
> known problem?  (Search didn't yield anything that looked similar to me.)
> 
> You can follow the exact steps and their consequences here: 
> https://github.com/rselph-tibco/go-unstable-mods/commits/master 
> 

[go-nuts] Re: Will the number of OS threads spawned by a golang process never decrease?

[Varun V]

I tried to post this message before I came 
across https://github.com/golang/go/issues/14592. I couldn't post it 
successfully then. I don't know why this message is posted now

On Thursday, September 19, 2019 at 8:56:39 PM UTC+5:30, Varun V wrote:
>
> Consider a golang program running on a system with GOMAXPROCS value 10. 
> Initially OS has spawned 10 threads for execution. Due to blocking system 
> calls, OS spawns 30 more threads resulting in 40 OS threads attached to the 
> process.After all the blocked system calls return, then will the process 
> still be having 40 OS threads? If yes, then can we conclude that the number 
> of OS threads mapped to a golang process can grow but never comes down? 
>
> Thanks,
> Varun
>

-- 
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/d7aa76cc-5835-42d1-8323-31434ccd6554%40googlegroups.com.

[go-nuts] Re: go.mod changes on each build, -mod=readonly can never work

[rselph]

Thanks for the tips.  I'll try to reproduce from the tip branch before 
filing a bug.

On Thursday, September 19, 2019 at 9:34:38 AM UTC-7, t hepudds wrote:
>
> Hello Russ,
>
> Usually, if you are not modifying your code, I think go.mod should be 
> stable across repeated identical invocations of something like 'go build' 
> or 'go install'.
>
> I think there were a similar sounding set of bugs fixed for Go 1.13, but 
> sounds like you are seeing this with Go 1.13.
>
> A more recent bug was this one, which I think was reported against Go 1.13:
>
>https://github.com/golang/go/issues/34086
>
> That particular bug has seemingly been fixed in the tip branch. It 
> probably is worth trying to see if you can reproduce with that fix in 
> place. A handy way to try with the latest from tip / master is:
>
> $ go get golang.org/dl/gotip
> $ gotip download 
>
> However, that might not solve it for you. 
>  
> If you still see the same behavior using 'gotip', then I would suggest 
> opening a new bug to make sure one of the people working on cmd/go takes a 
> look. It looks like you already have nicely pulled together a public 
> reproducer, which is great.
>
> Finally, does 'go mod tidy' seem to be stable in terms of how it leaves 
> go.mod?  If so, one approach in the short term might be to run 'go mod 
> tidy' to put go.mod into a more stable state (e.g., after running 'go 
> install'), but given you seem to be seeing a bug, I'm not sure if that will 
> work for you.
>
> Regards,
> thepudds
>
> On Wednesday, September 18, 2019 at 7:38:41 PM UTC-4, Russ Selph wrote:
>>
>> Hi,
>>
>> I've got a modules problem, and I'm not sure yet whether it's operator 
>> error or something worthy of a bug report.  In short, I have a build where 
>> go.mod oscillates between two states build by build.  The first build 
>> changes it one way, the next build changes it back.  If I try the build 
>> with -mod=readonly, it will always fail because every build wants to change 
>> go.mod.  This is a real problem for source control.  :-)
>>
>> I've put together a toy project that demonstrates the problem.  It's 
>> based on our real world project, which is pretty large.  This one has no 
>> code of any consequence, but is an exact model of the external dependencies.
>>
>> https://github.com/rselph-tibco/go-unstable-mods
>>
>> There are two programs and two packages, all contained in two modules, 
>> with a sort of twisted interdependency.  But it seems to be the external 
>> dependencies that are messing things up.  On subsequent builds of sample1, 
>> the go.mod file  does this:
>>
>> foo.com/me/sample2 v0.0.0-0001010100-
>> github.com/coreos/bbolt v1.3.3
>> github.com/coreos/etcd v3.3.15+incompatible
>> -   github.com/coreos/go-semver v0.3.0 // indirect
>> github.com/elazarl/go-bindata-assetfs v1.0.0
>> github.com/gorilla/mux v1.7.3
>> -   github.com/json-iterator/go v1.1.7 // indirect
>> github.com/magiconair/properties v1.8.1
>> -   github.com/modern-go/reflect2 v1.0.1 // indirect
>> github.com/satori/go.uuid v1.2.0
>> golang.org/x/net v0.0.0-20190918130420-a8b05e9114ab
>>
>> then this:
>>
>> foo.com/me/sample2 v0.0.0-0001010100-
>> github.com/coreos/bbolt v1.3.3
>> github.com/coreos/etcd v3.3.15+incompatible
>> +   github.com/coreos/go-semver v0.3.0 // indirect
>> github.com/elazarl/go-bindata-assetfs v1.0.0
>> github.com/gorilla/mux v1.7.3
>> +   github.com/json-iterator/go v1.1.7 // indirect
>> github.com/magiconair/properties v1.8.1
>> +   github.com/modern-go/reflect2 v1.0.1 // indirect
>> github.com/satori/go.uuid v1.2.0
>> golang.org/x/net v0.0.0-20190918130420-a8b05e9114ab
>>
>> What's the best way to debug what's going on here?  Does this look like 
>> any known problem?  (Search didn't yield anything that looked similar to 
>> me.)
>>
>> You can follow the exact steps and their consequences here: 
>> https://github.com/rselph-tibco/go-unstable-mods/commits/master
>> All of that was generated by the script at 
>> https://github.com/rselph-tibco/go-unstable-mods/blob/master/run.sh
>>
>

-- 
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/eeb8a4e6-feca-4a80-8606-00d2e5c07fd0%40googlegroups.com.

[go-nuts] Testing changes to Go SSA?

[Mohit Verma]

Hi,

I added a new pass to Go SSA for experimental purposes. Is there a
testsuite to make sure Go's SSA backend works as intended? I do see some
test files in ssa/ and gc/ directory but they seem to be testing specific
cases in the code.
For example, Are there
1. tests that would test the compilation of big files?
OR, 2. tests to make sure high-level code constructs (like FOR LOOP)
compile down to no more than "x" instructions for some value of x?

Or is there a general testsuite that language developers use to test
compiler changes? I see this:
https://github.com/Byron/benchmarksgame-cvs-mirror but I am not sure if
this is the right place to look at.


Thanks!
Mohit

-- 
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/CAJ%2B6RRUSVO1xwnBCW5Ui7YGOx%3Dn2kG0L1kaUXBcuwBoPqjxJgQ%40mail.gmail.com.

Re: [go-nuts] go.mod changes on each build, -mod=readonly can never work

['Russ Selph' via golang-nuts]

I’ve filed this as #34417, at https://github.com/golang/go/issues/34417 


> On Sep 19, 2019, at 09:52, Russ Selph  wrote:
> 
> Thanks for the hints.  I'll try to reproduce from the tip branch before 
> filing a bug.
> 
>> On Sep 19, 2019, at 09:34, t hepudds > > wrote:
>> 
>> Hello Russ,
>> 
>> Usually, if you are not modifying your code, I think go.mod should be stable 
>> across repeated identical invocations of something like 'go build' or 'go 
>> install'.
>> 
>> I think there were a similar sounding set of bugs fixed for Go 1.13, but 
>> sounds like you are seeing this with Go 1.13.
>> 
>> A more recent bug was this one, which I think was reported against Go 1.13:
>> 
>>https://github.com/golang/go/issues/34086 
>> 
>> 
>> That particular bug has seemingly been fixed in the tip branch. It probably 
>> is worth trying to see if you can reproduce with that fix in place. A handy 
>> way to try with the latest from tip / master is:
>> 
>> $ go get golang.org/dl/gotip 
>> $ gotip download 
>> 
>> However, that might not solve it for you. 
>>  
>> If you still see the same behavior using 'gotip', then I would suggest 
>> opening a new bug to make sure one of the people working on cmd/go takes a 
>> look. It looks like you already have nicely pulled together a public 
>> reproducer, which is great.
>> 
>> Finally, does 'go mod tidy' seem to be stable in terms of how it leaves 
>> go.mod?  If so, one approach in the short term might be to run 'go mod tidy' 
>> to put go.mod into a more stable state (e.g., after running 'go install'), 
>> but given you seem to be seeing a bug, I'm not sure if that will work for 
>> you.
>> 
>> Regards,
>> thepudds
>> 
>> On Wednesday, September 18, 2019 at 7:38:41 PM UTC-4, Russ Selph wrote:
>> Hi,
>> 
>> I've got a modules problem, and I'm not sure yet whether it's operator error 
>> or something worthy of a bug report.  In short, I have a build where go.mod 
>> oscillates between two states build by build.  The first build changes it 
>> one way, the next build changes it back.  If I try the build with 
>> -mod=readonly, it will always fail because every build wants to change 
>> go.mod.  This is a real problem for source control.  :-)
>> 
>> I've put together a toy project that demonstrates the problem.  It's based 
>> on our real world project, which is pretty large.  This one has no code of 
>> any consequence, but is an exact model of the external dependencies.
>> 
>> https://github.com/rselph-tibco/go-unstable-mods 
>> 
>> 
>> There are two programs and two packages, all contained in two modules, with 
>> a sort of twisted interdependency.  But it seems to be the external 
>> dependencies that are messing things up.  On subsequent builds of sample1, 
>> the go.mod file  does this:
>> 
>> foo.com/me/sample2  
>> v0.0.0-0001010100-
>> github.com/coreos/bbolt  v1.3.3
>> github.com/coreos/etcd  
>> v3.3.15+incompatible
>> -   github.com/coreos/go-semver  v0.3.0 
>> // indirect
>> github.com/elazarl/go-bindata-assetfs 
>>  v1.0.0
>> github.com/gorilla/mux  v1.7.3
>> -   github.com/json-iterator/go  v1.1.7 
>> // indirect
>> github.com/magiconair/properties 
>>  v1.8.1
>> -   github.com/modern-go/reflect2  
>> v1.0.1 // indirect
>> github.com/satori/go.uuid  v1.2.0
>> golang.org/x/net  
>> v0.0.0-20190918130420-a8b05e9114ab
>> 
>> then this:
>> 
>> foo.com/me/sample2  
>> v0.0.0-0001010100-
>> github.com/coreos/bbolt  v1.3.3
>> github.com/coreos/etcd  
>> v3.3.15+incompatible
>> +   github.com/coreos/go-semver  v0.3.0 
>> // indirect
>> github.com/elazarl/go-bindata-assetfs 
>>  v1.0.0
>> github.com/gorilla/mux  v1.7.3
>> +   github.com/json-iterator/go  v1.1.7 
>> // indirect
>> github.com/magiconair/properties 
>>  v1.8.1
>> +   github.com/modern-go/reflect2  
>> v1.0.1 // indirect
>> github.com/satori/go.uuid  v1.2.0
>> golang.org/x/net  
>> v0.0.0-20190918130420-a8b05e9114ab
>> 
>> What's the best way to debug what's g

[go-nuts] Re: Testing changes to Go SSA?

[keith . randall]

In addition to the tests you saw, there are a bunch of tests in 
test/codegen that makes sure specific sequences of instructions are or are 
not generated.
Tests for specific issues that have been fixed are in test/fixedbugs.
Generally the whole test suite is one giant compiler test. Run all.bash and 
if it passes, you can be pretty sure the compiler is generating correct 
code.
There are other tests, like compilebench, which you can use to check the 
resource use of the compiler.

On Thursday, September 19, 2019 at 3:28:04 PM UTC-7, Mohit Verma wrote:
>
> Hi,
>
> I added a new pass to Go SSA for experimental purposes. Is there a 
> testsuite to make sure Go's SSA backend works as intended? I do see some 
> test files in ssa/ and gc/ directory but they seem to be testing specific 
> cases in the code.
> For example, Are there 
> 1. tests that would test the compilation of big files? 
> OR, 2. tests to make sure high-level code constructs (like FOR LOOP) 
> compile down to no more than "x" instructions for some value of x?
>
> Or is there a general testsuite that language developers use to test 
> compiler changes? I see this: 
> https://github.com/Byron/benchmarksgame-cvs-mirror but I am not sure if 
> this is the right place to look at. 
>
>
> Thanks!
> Mohit
>
>

-- 
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/cc238d35-fc59-4572-bd2c-df5dda7539b0%40googlegroups.com.

[go-nuts] Re: Testing changes to Go SSA?

[keith . randall]

In addition to the tests you saw, there are a bunch of tests in 
test/codegen that makes sure specific sequences of instructions are or are 
not generated.
Tests for specific issues that have been fixed are in test/fixedbugs.
Generally the whole test suite is one giant compiler test. Run all.bash and 
if it passes, you can be pretty sure the compiler is generating correct 
code.
There are other tests, like compilebench, which you can use to check the 
resource use of the compiler.

On Thursday, September 19, 2019 at 3:28:04 PM UTC-7, Mohit Verma wrote:
>
> Hi,
>
> I added a new pass to Go SSA for experimental purposes. Is there a 
> testsuite to make sure Go's SSA backend works as intended? I do see some 
> test files in ssa/ and gc/ directory but they seem to be testing specific 
> cases in the code.
> For example, Are there 
> 1. tests that would test the compilation of big files? 
> OR, 2. tests to make sure high-level code constructs (like FOR LOOP) 
> compile down to no more than "x" instructions for some value of x?
>
> Or is there a general testsuite that language developers use to test 
> compiler changes? I see this: 
> https://github.com/Byron/benchmarksgame-cvs-mirror but I am not sure if 
> this is the right place to look at. 
>
>
> Thanks!
> Mohit
>
>

-- 
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/1966d4dc-b251-46df-bcfb-0ba4d1aa33cc%40googlegroups.com.

[go-nuts] Re: Testing changes to Go SSA?

[keith . randall]

In addition to the tests you saw, there are a bunch of tests in 
test/codegen that makes sure specific sequences of instructions are or are 
not generated.
Tests for specific issues that have been fixed are in test/fixedbugs.
Generally the whole test suite is one giant compiler test. Run all.bash and 
if it passes, you can be pretty sure the compiler is generating correct 
code.
There are other tests, like compilebench, which you can use to check the 
resource use of the compiler.

On Thursday, September 19, 2019 at 3:28:04 PM UTC-7, Mohit Verma wrote:
>
> Hi,
>
> I added a new pass to Go SSA for experimental purposes. Is there a 
> testsuite to make sure Go's SSA backend works as intended? I do see some 
> test files in ssa/ and gc/ directory but they seem to be testing specific 
> cases in the code.
> For example, Are there 
> 1. tests that would test the compilation of big files? 
> OR, 2. tests to make sure high-level code constructs (like FOR LOOP) 
> compile down to no more than "x" instructions for some value of x?
>
> Or is there a general testsuite that language developers use to test 
> compiler changes? I see this: 
> https://github.com/Byron/benchmarksgame-cvs-mirror but I am not sure if 
> this is the right place to look at. 
>
>
> Thanks!
> Mohit
>
>

-- 
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/c039ca75-87da-4c19-a377-20ff82f93e95%40googlegroups.com.

Re: [go-nuts] Re: Will the number of OS threads spawned by a golang process never decrease?

[Ian Lance Taylor]

On Thu, Sep 19, 2019 at 10:25 AM Varun V  wrote:
>
> I tried to post this message before I came across 
> https://github.com/golang/go/issues/14592. I couldn't post it successfully 
> then. I don't know why this message is posted now

As it says at https://groups.google.com/forum/?pli=1#!forum/golang-nuts:
"Note: This group is moderated. If you are a first-time poster it may
take 24 hours for your post to appear in the group."

Sorry for the confusion.

Ian

-- 
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/CAOyqgcV9ZBj%2BERn0wvDEzw7%3D%3DZbYuODuuuUkCSTUQw6Gdrd5qw%40mail.gmail.com.

[go-nuts] Re: Testing changes to Go SSA?

['Isaac Gouy' via golang-nuts]

> Or is there a general testsuite that language developers use to test 
> compiler changes? I see this: 
> https://github.com/Byron/benchmarksgame-cvs-mirror but I am not sure if 
> this is the right place to look at. 
>


That github site seems very out-of-date. 


https://salsa.debian.org/benchmarksgame-team/benchmarksgame/blob/master/README.md

-- 
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/d00957c3-bfad-4d88-8e16-68691b2fde63%40googlegroups.com.