FAQ
Hi, all,
I'm looking at division rewrite in walk.go:walkdiv() function.

From the code and walk dump of my test function, it seems there should be
*no* const division optimization for "int" type. But the assembly shows
there *is* such optimisation (because there is no div instruction in dumped
assembly). Do you know where such optimization is done?

== test function start ==
func foo(x int) int {
    return x / 7
}
== test function end ==

== compile -W start ==
before foo
. RETURN l(6) tc(1)
. RETURN-list
. . DIV l(6) tc(1) int
. . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM) f(1)
tc(1) used(true) int
. . . LITERAL-7 l(10) tc(1) int
after walk foo
. RETURN l(6) tc(1)
. RETURN-list
. . AS u(2) l(6) tc(1)
. . . NAME-main.~r1 u(1) a(true) g(1) l(5) x(8+0) class(PPARAMOUT)
f(1) int
. . . DIV u(2) l(6) tc(1) int
. . . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM)
f(1) tc(1) used(true) int
. . . . LITERAL-7 u(1) a(true) l(10) tc(1) int
== compile -W end ==

== assembly start==
"".foo t=1 size=48 args=0x10 locals=0x0
         0x0000 00000 (main.go:5) TEXT "".foo(SB), $0-16
         0x0000 00000 (main.go:5) NOP
         0x0000 00000 (main.go:5) NOP
         0x0000 00000 (main.go:5) FUNCDATA $0,
gclocals·23e8278e2b69a3a75fa59b23c49ed6ad(SB)
         0x0000 00000 (main.go:5) FUNCDATA $1,
gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
         0x0000 00000 (main.go:6) MOVQ "".x+8(FP), BP
         0x0005 00005 (main.go:6) MOVQ $5270498306774157605, R9
         0x000f 00015 (main.go:6) MOVQ BP, AX
         0x0012 00018 (main.go:6) IMULQ R9
         0x0015 00021 (main.go:6) MOVQ DX, R8
         0x0018 00024 (main.go:6) SARQ $1, R8
         0x001b 00027 (main.go:6) SARQ $63, BP
         0x001f 00031 (main.go:6) SUBQ BP, R8
         0x0022 00034 (main.go:6) MOVQ R8, "".~r1+16(FP)
         0x0027 00039 (main.go:6) RET
== assembly end==

--
Best regards,
Zhongwei

--
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/d/optout.

Search Discussions

  • Ilya Tocar at Apr 5, 2016 at 10:41 am
    Hi,

    Looks like you are using AMD64 system.
    If you are on trunk, that means that your code is optimized by SSA backend.
    For signed divide -> multiply you should look at:
    cmd/compile/internal/ssa/gen/generic.rules

    вторник, 5 апреля 2016 г., 8:16:05 UTC+3 пользователь Zhongwei Yao написал:
    Hi, all,
    I'm looking at division rewrite in walk.go:walkdiv() function.

    From the code and walk dump of my test function, it seems there should be
    *no* const division optimization for "int" type. But the assembly shows
    there *is* such optimisation (because there is no div instruction in dumped
    assembly). Do you know where such optimization is done?

    == test function start ==
    func foo(x int) int {
    return x / 7
    }
    == test function end ==

    == compile -W start ==
    before foo
    . RETURN l(6) tc(1)
    . RETURN-list
    . . DIV l(6) tc(1) int
    . . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM) f(1)
    tc(1) used(true) int
    . . . LITERAL-7 l(10) tc(1) int
    after walk foo
    . RETURN l(6) tc(1)
    . RETURN-list
    . . AS u(2) l(6) tc(1)
    . . . NAME-main.~r1 u(1) a(true) g(1) l(5) x(8+0) class(PPARAMOUT)
    f(1) int
    . . . DIV u(2) l(6) tc(1) int
    . . . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM)
    f(1) tc(1) used(true) int
    . . . . LITERAL-7 u(1) a(true) l(10) tc(1) int
    == compile -W end ==

    == assembly start==
    "".foo t=1 size=48 args=0x10 locals=0x0
    0x0000 00000 (main.go:5) TEXT "".foo(SB), $0-16
    0x0000 00000 (main.go:5) NOP
    0x0000 00000 (main.go:5) NOP
    0x0000 00000 (main.go:5) FUNCDATA $0,
    gclocals·23e8278e2b69a3a75fa59b23c49ed6ad(SB)
    0x0000 00000 (main.go:5) FUNCDATA $1,
    gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
    0x0000 00000 (main.go:6) MOVQ "".x+8(FP), BP
    0x0005 00005 (main.go:6) MOVQ $5270498306774157605, R9
    0x000f 00015 (main.go:6) MOVQ BP, AX
    0x0012 00018 (main.go:6) IMULQ R9
    0x0015 00021 (main.go:6) MOVQ DX, R8
    0x0018 00024 (main.go:6) SARQ $1, R8
    0x001b 00027 (main.go:6) SARQ $63, BP
    0x001f 00031 (main.go:6) SUBQ BP, R8
    0x0022 00034 (main.go:6) MOVQ R8, "".~r1+16(FP)
    0x0027 00039 (main.go:6) RET
    == assembly end==

    --
    Best regards,
    Zhongwei
    --
    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/d/optout.
  • Zhongwei Yao at Apr 5, 2016 at 12:09 pm
    Hi, Thanks for your reply. I've checked there are "div" rules in
    generic.rules. And I was on trunk.

    But I do a test on branch 1.5 just now (go version go1.5.2 darwin/amd64
    without SSA back-end). It gives same result. I feel there is some stage
    that do similar thing as current trunk's SSA-backend. If anyone could point
    where is it, it would be helpful!
    On 5 April 2016 at 18:41, wrote:

    Hi,

    Looks like you are using AMD64 system.
    If you are on trunk, that means that your code is optimized by SSA backend.
    For signed divide -> multiply you should look at:
    cmd/compile/internal/ssa/gen/generic.rules

    вторник, 5 апреля 2016 г., 8:16:05 UTC+3 пользователь Zhongwei Yao написал:
    Hi, all,
    I'm looking at division rewrite in walk.go:walkdiv() function.

    From the code and walk dump of my test function, it seems there should be
    *no* const division optimization for "int" type. But the assembly shows
    there *is* such optimisation (because there is no div instruction in dumped
    assembly). Do you know where such optimization is done?

    == test function start ==
    func foo(x int) int {
    return x / 7
    }
    == test function end ==

    == compile -W start ==
    before foo
    . RETURN l(6) tc(1)
    . RETURN-list
    . . DIV l(6) tc(1) int
    . . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM) f(1)
    tc(1) used(true) int
    . . . LITERAL-7 l(10) tc(1) int
    after walk foo
    . RETURN l(6) tc(1)
    . RETURN-list
    . . AS u(2) l(6) tc(1)
    . . . NAME-main.~r1 u(1) a(true) g(1) l(5) x(8+0) class(PPARAMOUT)
    f(1) int
    . . . DIV u(2) l(6) tc(1) int
    . . . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM)
    f(1) tc(1) used(true) int
    . . . . LITERAL-7 u(1) a(true) l(10) tc(1) int
    == compile -W end ==

    == assembly start==
    "".foo t=1 size=48 args=0x10 locals=0x0
    0x0000 00000 (main.go:5) TEXT "".foo(SB), $0-16
    0x0000 00000 (main.go:5) NOP
    0x0000 00000 (main.go:5) NOP
    0x0000 00000 (main.go:5) FUNCDATA $0,
    gclocals·23e8278e2b69a3a75fa59b23c49ed6ad(SB)
    0x0000 00000 (main.go:5) FUNCDATA $1,
    gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
    0x0000 00000 (main.go:6) MOVQ "".x+8(FP), BP
    0x0005 00005 (main.go:6) MOVQ $5270498306774157605, R9
    0x000f 00015 (main.go:6) MOVQ BP, AX
    0x0012 00018 (main.go:6) IMULQ R9
    0x0015 00021 (main.go:6) MOVQ DX, R8
    0x0018 00024 (main.go:6) SARQ $1, R8
    0x001b 00027 (main.go:6) SARQ $63, BP
    0x001f 00031 (main.go:6) SUBQ BP, R8
    0x0022 00034 (main.go:6) MOVQ R8, "".~r1+16(FP)
    0x0027 00039 (main.go:6) RET
    == assembly end==

    --
    Best regards,
    Zhongwei
    --
    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/d/optout.


    --
    Best regards,
    Zhongwei

    --
    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/d/optout.
  • Dave Cheney at Apr 5, 2016 at 12:21 pm
    It's in he front-end, from memory the function is called walkdiv
    On Tue, 5 Apr 2016, 22:09 Zhongwei Yao, wrote:

    Hi, Thanks for your reply. I've checked there are "div" rules in
    generic.rules. And I was on trunk.

    But I do a test on branch 1.5 just now (go version go1.5.2 darwin/amd64
    without SSA back-end). It gives same result. I feel there is some stage
    that do similar thing as current trunk's SSA-backend. If anyone could point
    where is it, it would be helpful!
    On 5 April 2016 at 18:41, wrote:

    Hi,

    Looks like you are using AMD64 system.
    If you are on trunk, that means that your code is optimized by SSA
    backend.
    For signed divide -> multiply you should look at:
    cmd/compile/internal/ssa/gen/generic.rules

    вторник, 5 апреля 2016 г., 8:16:05 UTC+3 пользователь Zhongwei Yao
    написал:
    Hi, all,
    I'm looking at division rewrite in walk.go:walkdiv() function.

    From the code and walk dump of my test function, it seems there should
    be *no* const division optimization for "int" type. But the assembly shows
    there *is* such optimisation (because there is no div instruction in dumped
    assembly). Do you know where such optimization is done?

    == test function start ==
    func foo(x int) int {
    return x / 7
    }
    == test function end ==

    == compile -W start ==
    before foo
    . RETURN l(6) tc(1)
    . RETURN-list
    . . DIV l(6) tc(1) int
    . . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM) f(1)
    tc(1) used(true) int
    . . . LITERAL-7 l(10) tc(1) int
    after walk foo
    . RETURN l(6) tc(1)
    . RETURN-list
    . . AS u(2) l(6) tc(1)
    . . . NAME-main.~r1 u(1) a(true) g(1) l(5) x(8+0) class(PPARAMOUT)
    f(1) int
    . . . DIV u(2) l(6) tc(1) int
    . . . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM)
    f(1) tc(1) used(true) int
    . . . . LITERAL-7 u(1) a(true) l(10) tc(1) int
    == compile -W end ==

    == assembly start==
    "".foo t=1 size=48 args=0x10 locals=0x0
    0x0000 00000 (main.go:5) TEXT "".foo(SB), $0-16
    0x0000 00000 (main.go:5) NOP
    0x0000 00000 (main.go:5) NOP
    0x0000 00000 (main.go:5) FUNCDATA $0,
    gclocals·23e8278e2b69a3a75fa59b23c49ed6ad(SB)
    0x0000 00000 (main.go:5) FUNCDATA $1,
    gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
    0x0000 00000 (main.go:6) MOVQ "".x+8(FP), BP
    0x0005 00005 (main.go:6) MOVQ $5270498306774157605, R9
    0x000f 00015 (main.go:6) MOVQ BP, AX
    0x0012 00018 (main.go:6) IMULQ R9
    0x0015 00021 (main.go:6) MOVQ DX, R8
    0x0018 00024 (main.go:6) SARQ $1, R8
    0x001b 00027 (main.go:6) SARQ $63, BP
    0x001f 00031 (main.go:6) SUBQ BP, R8
    0x0022 00034 (main.go:6) MOVQ R8, "".~r1+16(FP)
    0x0027 00039 (main.go:6) RET
    == assembly end==

    --
    Best regards,
    Zhongwei
    --
    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/d/optout.


    --
    Best regards,
    Zhongwei

    --
    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/d/optout.
    --
    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/d/optout.
  • Zhongwei Yao at Apr 5, 2016 at 1:14 pm
    Hi, Dave, I was looking at walkdiv() function exactly. The problem is I
    think there should be no div optimization for "int" type (I come to this
    point after reading walkdiv() and checking the "compile -W" output of my
    test function). But the dumped assembly shows there *is* such optimization.
    On 5 April 2016 at 20:21, Dave Cheney wrote:

    It's in he front-end, from memory the function is called walkdiv
    On Tue, 5 Apr 2016, 22:09 Zhongwei Yao, wrote:

    Hi, Thanks for your reply. I've checked there are "div" rules in
    generic.rules. And I was on trunk.

    But I do a test on branch 1.5 just now (go version go1.5.2 darwin/amd64
    without SSA back-end). It gives same result. I feel there is some stage
    that do similar thing as current trunk's SSA-backend. If anyone could point
    where is it, it would be helpful!
    On 5 April 2016 at 18:41, wrote:

    Hi,

    Looks like you are using AMD64 system.
    If you are on trunk, that means that your code is optimized by SSA
    backend.
    For signed divide -> multiply you should look at:
    cmd/compile/internal/ssa/gen/generic.rules

    вторник, 5 апреля 2016 г., 8:16:05 UTC+3 пользователь Zhongwei Yao
    написал:
    Hi, all,
    I'm looking at division rewrite in walk.go:walkdiv() function.

    From the code and walk dump of my test function, it seems there should
    be *no* const division optimization for "int" type. But the assembly shows
    there *is* such optimisation (because there is no div instruction in dumped
    assembly). Do you know where such optimization is done?

    == test function start ==
    func foo(x int) int {
    return x / 7
    }
    == test function end ==

    == compile -W start ==
    before foo
    . RETURN l(6) tc(1)
    . RETURN-list
    . . DIV l(6) tc(1) int
    . . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM)
    f(1) tc(1) used(true) int
    . . . LITERAL-7 l(10) tc(1) int
    after walk foo
    . RETURN l(6) tc(1)
    . RETURN-list
    . . AS u(2) l(6) tc(1)
    . . . NAME-main.~r1 u(1) a(true) g(1) l(5) x(8+0)
    class(PPARAMOUT) f(1) int
    . . . DIV u(2) l(6) tc(1) int
    . . . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM)
    f(1) tc(1) used(true) int
    . . . . LITERAL-7 u(1) a(true) l(10) tc(1) int
    == compile -W end ==

    == assembly start==
    "".foo t=1 size=48 args=0x10 locals=0x0
    0x0000 00000 (main.go:5) TEXT "".foo(SB), $0-16
    0x0000 00000 (main.go:5) NOP
    0x0000 00000 (main.go:5) NOP
    0x0000 00000 (main.go:5) FUNCDATA $0,
    gclocals·23e8278e2b69a3a75fa59b23c49ed6ad(SB)
    0x0000 00000 (main.go:5) FUNCDATA $1,
    gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
    0x0000 00000 (main.go:6) MOVQ "".x+8(FP), BP
    0x0005 00005 (main.go:6) MOVQ $5270498306774157605, R9
    0x000f 00015 (main.go:6) MOVQ BP, AX
    0x0012 00018 (main.go:6) IMULQ R9
    0x0015 00021 (main.go:6) MOVQ DX, R8
    0x0018 00024 (main.go:6) SARQ $1, R8
    0x001b 00027 (main.go:6) SARQ $63, BP
    0x001f 00031 (main.go:6) SUBQ BP, R8
    0x0022 00034 (main.go:6) MOVQ R8, "".~r1+16(FP)
    0x0027 00039 (main.go:6) RET
    == assembly end==

    --
    Best regards,
    Zhongwei
    --
    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/d/optout.


    --
    Best regards,
    Zhongwei

    --
    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/d/optout.

    --
    Best regards,
    Zhongwei

    --
    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/d/optout.
  • Dave Cheney at Apr 5, 2016 at 1:28 pm
    Maybe int has already been lowered to int64 at this point. Or are you
    talking about int vs uint ?
    On Tue, Apr 5, 2016 at 11:14 PM, Zhongwei Yao wrote:
    Hi, Dave, I was looking at walkdiv() function exactly. The problem is I
    think there should be no div optimization for "int" type (I come to this
    point after reading walkdiv() and checking the "compile -W" output of my
    test function). But the dumped assembly shows there *is* such optimization.
    On 5 April 2016 at 20:21, Dave Cheney wrote:

    It's in he front-end, from memory the function is called walkdiv

    On Tue, 5 Apr 2016, 22:09 Zhongwei Yao, wrote:

    Hi, Thanks for your reply. I've checked there are "div" rules in
    generic.rules. And I was on trunk.

    But I do a test on branch 1.5 just now (go version go1.5.2 darwin/amd64
    without SSA back-end). It gives same result. I feel there is some stage that
    do similar thing as current trunk's SSA-backend. If anyone could point where
    is it, it would be helpful!
    On 5 April 2016 at 18:41, wrote:

    Hi,

    Looks like you are using AMD64 system.
    If you are on trunk, that means that your code is optimized by SSA
    backend.
    For signed divide -> multiply you should look at:
    cmd/compile/internal/ssa/gen/generic.rules

    вторник, 5 апреля 2016 г., 8:16:05 UTC+3 пользователь Zhongwei Yao
    написал:
    Hi, all,
    I'm looking at division rewrite in walk.go:walkdiv() function.

    From the code and walk dump of my test function, it seems there should
    be *no* const division optimization for "int" type. But the assembly shows
    there *is* such optimisation (because there is no div instruction in dumped
    assembly). Do you know where such optimization is done?

    == test function start ==
    func foo(x int) int {
    return x / 7
    }
    == test function end ==

    == compile -W start ==
    before foo
    . RETURN l(6) tc(1)
    . RETURN-list
    . . DIV l(6) tc(1) int
    . . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM)
    f(1) tc(1) used(true) int
    . . . LITERAL-7 l(10) tc(1) int
    after walk foo
    . RETURN l(6) tc(1)
    . RETURN-list
    . . AS u(2) l(6) tc(1)
    . . . NAME-main.~r1 u(1) a(true) g(1) l(5) x(8+0)
    class(PPARAMOUT) f(1) int
    . . . DIV u(2) l(6) tc(1) int
    . . . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM)
    f(1) tc(1) used(true) int
    . . . . LITERAL-7 u(1) a(true) l(10) tc(1) int
    == compile -W end ==

    == assembly start==
    "".foo t=1 size=48 args=0x10 locals=0x0
    0x0000 00000 (main.go:5) TEXT "".foo(SB), $0-16
    0x0000 00000 (main.go:5) NOP
    0x0000 00000 (main.go:5) NOP
    0x0000 00000 (main.go:5) FUNCDATA $0,
    gclocals·23e8278e2b69a3a75fa59b23c49ed6ad(SB)
    0x0000 00000 (main.go:5) FUNCDATA $1,
    gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
    0x0000 00000 (main.go:6) MOVQ "".x+8(FP), BP
    0x0005 00005 (main.go:6) MOVQ $5270498306774157605,
    R9
    0x000f 00015 (main.go:6) MOVQ BP, AX
    0x0012 00018 (main.go:6) IMULQ R9
    0x0015 00021 (main.go:6) MOVQ DX, R8
    0x0018 00024 (main.go:6) SARQ $1, R8
    0x001b 00027 (main.go:6) SARQ $63, BP
    0x001f 00031 (main.go:6) SUBQ BP, R8
    0x0022 00034 (main.go:6) MOVQ R8, "".~r1+16(FP)
    0x0027 00039 (main.go:6) RET
    == assembly end==

    --
    Best regards,
    Zhongwei
    --
    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/d/optout.



    --
    Best regards,
    Zhongwei

    --
    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/d/optout.



    --
    Best regards,
    Zhongwei
    --
    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/d/optout.
  • Matthew Dempsky at Apr 5, 2016 at 5:47 pm

    On Tue, Apr 5, 2016 at 6:14 AM, Zhongwei Yao wrote:

    Hi, Dave, I was looking at walkdiv() function exactly. The problem is I
    think there should be no div optimization for "int" type (I come to this
    point after reading walkdiv() and checking the "compile -W" output of my
    test function). But the dumped assembly shows there *is* such optimization.
    Rewriting 64-bit division into multiplication is handled in
    cmd/compile/internal/gc/cgen.go:cgen_div.

    --
    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/d/optout.
  • Matthew Dempsky at Apr 5, 2016 at 5:58 pm
    Sorry, that's where it *was* handled, before SSA.

    Under SSA it's handled by the Div64 "magic" rewrite rules. For example, in
    ssa/gen/generic.rules:

    // Signed divide, not a power of 2. Strength reduce to a multiply.
    (Div64 <t> x (Const64 [c])) && c > 0 && smagic64ok(c) && smagic64m(c) > 0 ->
       (Sub64 <t>
         (Rsh64x64 <t>
           (Hmul64 <t>
             (Const64 <t> [smagic64m(c)])
             x)
           (Const64 <t> [smagic64s(c)]))
         (Rsh64x64 <t>
           x
           (Const64 <t> [63])))

    On Tue, Apr 5, 2016 at 10:46 AM, Matthew Dempsky wrote:
    On Tue, Apr 5, 2016 at 6:14 AM, Zhongwei Yao wrote:

    Hi, Dave, I was looking at walkdiv() function exactly. The problem is I
    think there should be no div optimization for "int" type (I come to this
    point after reading walkdiv() and checking the "compile -W" output of my
    test function). But the dumped assembly shows there *is* such optimization.
    Rewriting 64-bit division into multiplication is handled in
    cmd/compile/internal/gc/cgen.go:cgen_div.
    --
    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/d/optout.
  • Zhongwei Yao at Apr 6, 2016 at 2:05 am
    Matthew, thanks! That is what I'm looking for.
    On 6 April 2016 at 01:58, Matthew Dempsky wrote:

    Sorry, that's where it *was* handled, before SSA.

    Under SSA it's handled by the Div64 "magic" rewrite rules. For example,
    in ssa/gen/generic.rules:

    // Signed divide, not a power of 2. Strength reduce to a multiply.
    (Div64 <t> x (Const64 [c])) && c > 0 && smagic64ok(c) && smagic64m(c) > 0
    ->
    (Sub64 <t>
    (Rsh64x64 <t>
    (Hmul64 <t>
    (Const64 <t> [smagic64m(c)])
    x)
    (Const64 <t> [smagic64s(c)]))
    (Rsh64x64 <t>
    x
    (Const64 <t> [63])))

    On Tue, Apr 5, 2016 at 10:46 AM, Matthew Dempsky wrote:

    On Tue, Apr 5, 2016 at 6:14 AM, Zhongwei Yao <zhongwei.yao@linaro.org>
    wrote:
    Hi, Dave, I was looking at walkdiv() function exactly. The problem is I
    think there should be no div optimization for "int" type (I come to this
    point after reading walkdiv() and checking the "compile -W" output of my
    test function). But the dumped assembly shows there *is* such optimization.
    Rewriting 64-bit division into multiplication is handled in
    cmd/compile/internal/gc/cgen.go:cgen_div.

    --
    Best regards,
    Zhongwei

    --
    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/d/optout.
  • Alexandru Moșoi at Apr 5, 2016 at 4:40 pm
    I added rules to fold modulo
    yesterday. https://go-review.googlesource.com/#/c/21501/. Feel free to
    duplicate the rules for div too and send me a patch for review.

    marți, 5 aprilie 2016, 07:16:05 UTC+2, Zhongwei Yao a scris:
    Hi, all,
    I'm looking at division rewrite in walk.go:walkdiv() function.

    From the code and walk dump of my test function, it seems there should be
    *no* const division optimization for "int" type. But the assembly shows
    there *is* such optimisation (because there is no div instruction in dumped
    assembly). Do you know where such optimization is done?

    == test function start ==
    func foo(x int) int {
    return x / 7
    }
    == test function end ==

    == compile -W start ==
    before foo
    . RETURN l(6) tc(1)
    . RETURN-list
    . . DIV l(6) tc(1) int
    . . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM) f(1)
    tc(1) used(true) int
    . . . LITERAL-7 l(10) tc(1) int
    after walk foo
    . RETURN l(6) tc(1)
    . RETURN-list
    . . AS u(2) l(6) tc(1)
    . . . NAME-main.~r1 u(1) a(true) g(1) l(5) x(8+0) class(PPARAMOUT)
    f(1) int
    . . . DIV u(2) l(6) tc(1) int
    . . . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM)
    f(1) tc(1) used(true) int
    . . . . LITERAL-7 u(1) a(true) l(10) tc(1) int
    == compile -W end ==

    == assembly start==
    "".foo t=1 size=48 args=0x10 locals=0x0
    0x0000 00000 (main.go:5) TEXT "".foo(SB), $0-16
    0x0000 00000 (main.go:5) NOP
    0x0000 00000 (main.go:5) NOP
    0x0000 00000 (main.go:5) FUNCDATA $0,
    gclocals·23e8278e2b69a3a75fa59b23c49ed6ad(SB)
    0x0000 00000 (main.go:5) FUNCDATA $1,
    gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
    0x0000 00000 (main.go:6) MOVQ "".x+8(FP), BP
    0x0005 00005 (main.go:6) MOVQ $5270498306774157605, R9
    0x000f 00015 (main.go:6) MOVQ BP, AX
    0x0012 00018 (main.go:6) IMULQ R9
    0x0015 00021 (main.go:6) MOVQ DX, R8
    0x0018 00024 (main.go:6) SARQ $1, R8
    0x001b 00027 (main.go:6) SARQ $63, BP
    0x001f 00031 (main.go:6) SUBQ BP, R8
    0x0022 00034 (main.go:6) MOVQ R8, "".~r1+16(FP)
    0x0027 00039 (main.go:6) RET
    == assembly end==

    --
    Best regards,
    Zhongwei
    --
    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/d/optout.
  • Alexandru Moșoi at Apr 5, 2016 at 4:45 pm
    Nvm, I didn't read the whole email and I had something else on my mind.

    marți, 5 aprilie 2016, 18:40:01 UTC+2, Alexandru Moșoi a scris:
    I added rules to fold modulo yesterday.
    https://go-review.googlesource.com/#/c/21501/. Feel free to duplicate the
    rules for div too and send me a patch for review.

    marți, 5 aprilie 2016, 07:16:05 UTC+2, Zhongwei Yao a scris:
    Hi, all,
    I'm looking at division rewrite in walk.go:walkdiv() function.

    From the code and walk dump of my test function, it seems there should be
    *no* const division optimization for "int" type. But the assembly shows
    there *is* such optimisation (because there is no div instruction in dumped
    assembly). Do you know where such optimization is done?

    == test function start ==
    func foo(x int) int {
    return x / 7
    }
    == test function end ==

    == compile -W start ==
    before foo
    . RETURN l(6) tc(1)
    . RETURN-list
    . . DIV l(6) tc(1) int
    . . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM) f(1)
    tc(1) used(true) int
    . . . LITERAL-7 l(10) tc(1) int
    after walk foo
    . RETURN l(6) tc(1)
    . RETURN-list
    . . AS u(2) l(6) tc(1)
    . . . NAME-main.~r1 u(1) a(true) g(1) l(5) x(8+0) class(PPARAMOUT)
    f(1) int
    . . . DIV u(2) l(6) tc(1) int
    . . . . NAME-main.x u(1) a(true) g(2) l(5) x(0+0) class(PPARAM)
    f(1) tc(1) used(true) int
    . . . . LITERAL-7 u(1) a(true) l(10) tc(1) int
    == compile -W end ==

    == assembly start==
    "".foo t=1 size=48 args=0x10 locals=0x0
    0x0000 00000 (main.go:5) TEXT "".foo(SB), $0-16
    0x0000 00000 (main.go:5) NOP
    0x0000 00000 (main.go:5) NOP
    0x0000 00000 (main.go:5) FUNCDATA $0,
    gclocals·23e8278e2b69a3a75fa59b23c49ed6ad(SB)
    0x0000 00000 (main.go:5) FUNCDATA $1,
    gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
    0x0000 00000 (main.go:6) MOVQ "".x+8(FP), BP
    0x0005 00005 (main.go:6) MOVQ $5270498306774157605, R9
    0x000f 00015 (main.go:6) MOVQ BP, AX
    0x0012 00018 (main.go:6) IMULQ R9
    0x0015 00021 (main.go:6) MOVQ DX, R8
    0x0018 00024 (main.go:6) SARQ $1, R8
    0x001b 00027 (main.go:6) SARQ $63, BP
    0x001f 00031 (main.go:6) SUBQ BP, R8
    0x0022 00034 (main.go:6) MOVQ R8, "".~r1+16(FP)
    0x0027 00039 (main.go:6) RET
    == assembly end==

    --
    Best regards,
    Zhongwei
    --
    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/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedApr 5, '16 at 5:16a
activeApr 6, '16 at 2:05a
posts11
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase