Planning Go 1.14

[Andrew Bonventre]

Now that Go 1.13rc1 is out, the Go repos have been branched ("release-branch.go1.13") so the Go 1.14 development tree will open soon on the "master" branches.

As before, we will soon open the tree for significant changes that need to be made early in the cycle, in relative quiet. We will not wait for the final release, however, for the tree to be open generally.

I will follow up this week with exact dates for when the tree will be open.

In the meantime, let's use this thread to discuss people's plans for Go 1.14.

(These are things you *PLAN TO DO YOURSELF*, not things you want other people to do.)

Thanks,

Andy

P.S. We really appreciate everyone's patience with 1.13's delay and will be conducting a thorough retrospective to identify and mitigate root causes. If you have any questions or concerns, please reach out on a separate thread either on golang-dev or to me personally. This thread is for planning.

[Matthew Dempsky]

On Wed, Aug 21, 2019 at 1:51 PM Andrew Bonventre <andy...@golang.org> wrote:

In the meantime, let's use this thread to discuss people's plans for Go 1.14.

I plan to remove the old escape analysis code from cmd/compile (https://go-review.googlesource.com/c/go/+/187598/2), and plug away at improving the new escape analysis where that becomes easier. In particular, I plan to improve the fidelity of escape analysis tagging to fix cases like:

package p

var g *int

//go:noinline

func f(p ***int) { g = **p }

func e() {

    var i int

    j := &i      // BAD: 'j' is currently heap allocated, but needn't be

    k := &j

    f(&k)

}

Also, I'm working on cleaning up cmd/compile's handling of untyped constants (WIP CL at https://go-review.googlesource.com/c/go/+/187657; still needs polish and will likely split into logically separate chunks). I'm hoping this will simplify some of the typechecking code and reduce allocations involved in constant calculations/conversions.

Depending on how much free time I have this cycle, two other larger projects I had in mind to try to work on:

1. Simplifying swt.go; in particular, the detection of constant runs and decomposition into binary searches / range checks is overly tricky and I think can be improved a lot.

2. Continuing along at moving order.go/walk.go/racewalk.go logic directly into the SSA builder code, or at least preparing for that.

    - There's some low hanging fruit here like moving walk.go's zeroResults/heapmoves and racewalk.go's code into SSA builder.

    - Maybe move walk.go's "declared and not used" checks earlier into typecheck.go; they really don't belong in the backend anyway.

    - Try to unify order.go and walk.go's recursive handling of control flow structures (OIF, OFOR, OBLOCK).

[Daniel Martí]

On Wed, Aug 21, 2019 at 16:51:17 -0400, Andrew Bonventre wrote:
> In the meantime, let's use this thread to discuss people's plans for Go 1.14.

This cycle, I intend to work on the compiler's rulegen program. A couple
of refactor CLs are ready to submit, which will make it easier to
maintain and improve its code generation in the future.

I also intend to make a couple of changes early in the cycle which might
surprise a few users; making 'go test' error when a test uses os.Exit,
and making the json decoder reuse existing map entries. Both will make
the packages more consistent and less bug-prone.

I will continue performance work in encoding/json too, though I think
all of the low-hanging fruit has been picked at this point. I might try
a larger internal refactor this cycle.

Finally, I'm sitting on a couple of proposal drafts that I might post to
the issue tracker in the coming weeks.

I'm at GopherCon UK today and tomorrow, so I'm happy to talk about these
topics (or anything else for Go 1.14) if any of you are around :)

[lab...@gmail.com]

I have three changes to crypto assembler for ppc64le that I'd like to get in this release. One is for elliptic, which has already been submitting but was reviewed too late for Go 1.13. I also have an asm implementation for gcm and an improvement to the current asm for chacha20 so it performs better on power9.

I have some minor updates to arch/ppc64asm and objdump so the output is closer to the binutils objdump. I also have a suggestion to add more information on the objdump output which Cherry suggested should be a proposal.

Beyond that, I am involved in 2 open issues now: one to improve rulegen so we avoid the explosion of rules in the rewrite file for commutable opcodes with many operands (#33644). The other is to avoid some unnecessary branching for cases where constants are being set then immediately compared against constants. (#33713)

I have some improvements to ISEL which are mostly clean up to the way they are done but in some cases eliminate unnecessary instructions.

[Roberto Clapis]

I plan to work on #9200 to address the xss risk detailed there and work on #31107 if it gets accepted.

[Akhil Indurti]

The primary work I want to do for 1.14 is landing the CLs for

the fused-multiply-add intrinsic (they are currently in review).

Additionally, I am going to try and speed up decoding in the

JPEG package. I am currently experimenting with an SSE2

implementation of the inverse discrete cosine transform.

[Agniva De Sarker]

I plan to focus on wasm stuff this cycle. Mainly code generation and other performance related things. I already have some CLs which will go in once the tree opens.

On the side, I will keep an eye on cmd/doc and go/doc and may pick up a thing or two as I go along.

[Bryan C. Mills]

For module-mode support, Jay and I are planning to address at least:

• replacements & renaming (#26904, maybe #30831)
• UX and behavior for ephemeral operations on the module graph (#32027, #33710, #29452)
• Subversion support in module mode (#26092)
• lots of documentation improvements (#33637)

At some point in the cycle I'm also planning to make another run at swapping the default of GO111MODULE back to `on`, as we tried (but reverted) for 1.13. (#30228)

That's already a pretty daunting list, but we will also try to get to:

• binary installation w/ replacements (#31173)
• UX improvements for vendoring (#27227, #29058; revised proposal forthcoming)
• private HTTPS authentication (#26232; note that Basic auth should already work using .netrc files in 1.13)
• error reporting, particularly in `go list -e` (various issues)
• module diagnostics, particularly for tagging and managing releases (#26420, #24031, #33124)
• “bug fixes and performance improvements”

We probably won't have enough time to finish all of those before the 1.14 freeze, but we know that they're all important.

[Guy Brandwine]

@Bryan

As for private HTTPS authentication (#26232; ) I have been experimenting with it (solving at least one specific case) so I would be glad to land a hand.

If I'll free some real time, I would work on WASM executable size, and perhaps tiny, still trying to find if my plans are not similar or in conflict with existing issues.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAKWVi_SEV639xER5qHzEagBUTNX1Sp9b%3D6rOQsoFfmxmUbrpHg%40mail.gmail.com.

[Ian Lance Taylor]

On Wed, Aug 21, 2019 at 1:51 PM Andrew Bonventre <andy...@golang.org> wrote:
>

> In the meantime, let's use this thread to discuss people's plans for Go 1.14.

I hope to get my series of timer changes
(https://golang.org/cl/171884) reviewed and committed.

Ian

[Baokun Lee]

I plan to focus on modules， try to fix some bugs reported via issues.

[Andrew Bonventre]

Thanks, everyone. We plan to open the tree Tuesday, August 27.

[ra...@develer.com]

I'm working on improving dead code elimination at linker time by removing generated init functions that initialize a symbol which is not otherwise referenced (golang.org/issues/19533). This doesn't currently happen because init functions obviously reference the global variable being initialized, and the init functions themselves are always marked as reachable. I've got a preliminary patch that doesn't work (= removes too many init functions) but it gives a threshold at the maximum size save I can obtain with this work: helloworld on macOS built with "-s -w" goes from 1.6M to 1.2M.

To remove an init function, you need to prove in the compiler that it doesn't have any side effect besides initializing the global variable, which in turns means agreeing on a definition of "side effects" (for instance, almost everything has a visibile effect under a step-by-step debugger, or when inspected with strace/ptrace). I plan to begin conservatively here: I'd like to land the whole infrastructure with a very pessimistic definition of "having a side effect" (eg: any function call is a side effect) and iterate from there, so that each subsequent CL improving the side effect detection (or rather, "no side effect" detection) can be discussed from a semantic point of view.

[Andrew Bonventre]

The tree is now open. 

[Rémy Oudompheng]

Le mer. 21 août 2019 à 22:51, Andrew Bonventre <andy...@golang.org> a écrit :
>
> Now that Go 1.13rc1 is out, the Go repos have been branched ("release-branch.go1.13") so the Go 1.14 development tree will open soon on the "master" branches.
>
> As before, we will soon open the tree for significant changes that need to be made early in the cycle, in relative quiet. We will not wait for the final release, however, for the tree to be open generally.
>
> I will follow up this week with exact dates for when the tree will be open.
>
> In the meantime, let's use this thread to discuss people's plans for Go 1.14.
>
> (These are things you *PLAN TO DO YOURSELF*, not things you want other people to do.)
>
> Thanks,
> Andy

Hello,

I would like some of my changes written earlier this year to make it
into 1.14 release (if they are desired of course):

- Ryu algorithm implementation for strconv:
https://go-review.googlesource.com/c/go/+/170078
https://go-review.googlesource.com/c/go/+/170079
https://go-review.googlesource.com/c/go/+/170080

- Recursive division implementation for math/big
https://go-review.googlesource.com/c/go/+/172018

I also have toy experiments for CRC/AES acceleration on 32-bit ARMv8.
However I don't know whether this is of any interest to anybody else
(the only platform where I can use it is my phone).

- https://github.com/remyoudompheng/go/tree/aarch32

Regards,
Rémy.

[Zach Jones]

This cycle I will continue work to improve the compiler's prove pass, mostly focused on eliminating redundant bounds checks. I have begun and attempt to implement on-demand inference in the prove pass (a la ABCD:Eliminating Array Bounds Checks on Demand). The state of my current attempt can be seen in in this CL and the related chain. I would greatly appreciate any feedback anyone may have.

If you know of issues that may be related to BCE, or could otherwise be fixed by the prove pass, please let me know (github: zdjones).

Best,

Zach