FAQ
I've been looking over the regopt passes for the last couple of days
for implementing common subexpression elimination. I didn't get
anywhere but I noticed that we have 2 instances of live variable
analysis in the code. One in cmd/gc/plive.c and another in
cmd/*g/reg.c. We're doing the analysis twice per compilation.

Are there any issues in consolidating these two passes?

Regards,
Daniel Morsing

--

---
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Russ Cox at Jan 13, 2014 at 4:46 pm

    On Tue, Jan 7, 2014 at 4:15 PM, Daniel Morsing wrote:

    I've been looking over the regopt passes for the last couple of days
    for implementing common subexpression elimination. I didn't get
    anywhere but I noticed that we have 2 instances of live variable
    analysis in the code. One in cmd/gc/plive.c and another in
    cmd/*g/reg.c. We're doing the analysis twice per compilation.

    Are there any issues in consolidating these two passes?
    The two passes operate at different levels. plive.c is working on variables
    but reg.c is working on words. So if you have a var x [2]int on the stack,
    plive treats that as one variable while reg treats it as two variables.
    plive.c is being used to compute the liveness for garbage collection maps,
    so it has to work no matter what; reg.c gives up if there are too many
    variables. It would be interesting to look into merging them at some point
    (with appropriate parametrization to preserve the different use cases), but
    I wouldn't bother until the compiler is converted to Go.

    For what it's worth, I don't think that's the right place to add common
    subexpression elimination. I think that would make more sense in a new
    middle representation (see phase 4b of the compiler plan).

    Russ

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Daniel Morsing at Jan 13, 2014 at 6:06 pm
    To the mailing list as well.


    ---------- Forwarded message ----------
    From: Daniel Morsing <daniel.morsing@gmail.com>
    Date: Mon, Jan 13, 2014 at 10:06 AM
    Subject: Re: Consolidating gc dataflow passes.
    To: Russ Cox <rsc@golang.org>

    On Mon, Jan 13, 2014 at 8:46 AM, Russ Cox wrote:
    On Tue, Jan 7, 2014 at 4:15 PM, Daniel Morsing wrote:

    I've been looking over the regopt passes for the last couple of days
    for implementing common subexpression elimination. I didn't get
    anywhere but I noticed that we have 2 instances of live variable
    analysis in the code. One in cmd/gc/plive.c and another in
    cmd/*g/reg.c. We're doing the analysis twice per compilation.

    Are there any issues in consolidating these two passes?

    The two passes operate at different levels. plive.c is working on variables
    but reg.c is working on words. So if you have a var x [2]int on the stack,
    plive treats that as one variable while reg treats it as two variables.
    plive.c is being used to compute the liveness for garbage collection maps,
    so it has to work no matter what; reg.c gives up if there are too many
    variables. It would be interesting to look into merging them at some point
    (with appropriate parametrization to preserve the different use cases), but
    I wouldn't bother until the compiler is converted to Go.

    For what it's worth, I don't think that's the right place to add common
    subexpression elimination. I think that would make more sense in a new
    middle representation (see phase 4b of the compiler plan).

    Russ
    Yeah, it's not the place for common subexpression elimination. I
    figured that out right after sending the email.

    Eventually, I'll be using dataflow analysis with CSE in order to
    eliminate some bounds checks. As the compiler starts doing more of
    these DFA passes (I think there's one for CHECKNIL as well?),
    standardizing the form might be worth doing.

    But that can wait for after the go switchover.

    Regards,
    Daniel Morsing

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Jan 14, 2014 at 7:52 am

    On Mon, Jan 13, 2014 at 10:06 PM, Daniel Morsing wrote:
    To the mailing list as well.


    ---------- Forwarded message ----------
    From: Daniel Morsing <daniel.morsing@gmail.com>
    Date: Mon, Jan 13, 2014 at 10:06 AM
    Subject: Re: Consolidating gc dataflow passes.
    To: Russ Cox <rsc@golang.org>

    On Mon, Jan 13, 2014 at 8:46 AM, Russ Cox wrote:
    On Tue, Jan 7, 2014 at 4:15 PM, Daniel Morsing <daniel.morsing@gmail.com>
    wrote:
    I've been looking over the regopt passes for the last couple of days
    for implementing common subexpression elimination. I didn't get
    anywhere but I noticed that we have 2 instances of live variable
    analysis in the code. One in cmd/gc/plive.c and another in
    cmd/*g/reg.c. We're doing the analysis twice per compilation.

    Are there any issues in consolidating these two passes?

    The two passes operate at different levels. plive.c is working on variables
    but reg.c is working on words. So if you have a var x [2]int on the stack,
    plive treats that as one variable while reg treats it as two variables.
    plive.c is being used to compute the liveness for garbage collection maps,
    so it has to work no matter what; reg.c gives up if there are too many
    variables. It would be interesting to look into merging them at some point
    (with appropriate parametrization to preserve the different use cases), but
    I wouldn't bother until the compiler is converted to Go.

    For what it's worth, I don't think that's the right place to add common
    subexpression elimination. I think that would make more sense in a new
    middle representation (see phase 4b of the compiler plan).

    Russ
    Yeah, it's not the place for common subexpression elimination. I
    figured that out right after sending the email.

    Eventually, I'll be using dataflow analysis with CSE in order to
    eliminate some bounds checks. As the compiler starts doing more of
    these DFA passes (I think there's one for CHECKNIL as well?),
    standardizing the form might be worth doing.

    But that can wait for after the go switchover.

    Please also take race detector into consideration:
    https://code.google.com/p/go/issues/detail?id=4247

    It needs something very similar to nil checks -- remove duplicate
    instrumentation of the same variable (in SSA meaning) in the same
    basic block (or if one dominates another if that's possible) if no
    function calls in between.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedJan 7, '14 at 9:15p
activeJan 14, '14 at 7:52a
posts4
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase