FAQ
I'd rather add all the bool generic ops. It just makes everything
clearer. For instance, we now have the following two rules:

(Eq8 x (Const8 <t> [c])) && x.Op != OpConst8 -> (Eq8 (Const8 <t> [c]) x)
(Eq8 x (ConstBool <t> [c])) && x.Op != OpConstBool -> (Eq8 (ConstBool <t>
[c]) x)

The latter one doesn't really make much sense. If we had EqBool we could do

(EqBool x (ConstBool [1])) -> x
(EqBool x (ConstBool [0])) -> (Not x)

On Fri, Apr 22, 2016 at 2:41 AM, Alexandru Moșoi wrote:

It's a bigger rabbit hole than that. If I add AndBool and OrBool then I
have to add EqBool and NeqBool and convert all usages of Eq8/Neq8/Or8 to
EqBool/NeqBool/OrBool. Then update the generic.rules. Maybe this is some
work for early Go1.8. For now I'd stick with And8 given Russ' argument
("the situation [...] that a&&b and a&b are different, cannot reasonably
happen"). The thing I care about is that the value of true is fixed, but
not the exact value (1 on amd64).

joi, 21 aprilie 2016, 00:26:02 UTC+2, Keith Randall a scris:
We can still lower to ANDB/ORB, we only need distinct ops for the generic
arch.


On Wed, Apr 20, 2016 at 3:12 PM, Alexandru Moșoi <alex...@mosoi.ro>
wrote:
We wouldn't need to add new ops. I don't like that because I think we'll
need to add rules wrt boolean optimizations that are now already handled by
ANDB/ORB/XORB rewrite rules. I guess new ops are a better solutions than
restricting future architectures.

miercuri, 20 aprilie 2016, 23:30:56 UTC+2, Austin Clements a scris:
I think David means: how much performance do we expect to gain by
making bools something other than 0 and 1?

On Wed, Apr 20, 2016 at 4:55 PM, 'David Chase' via golang-dev <
golan...@googlegroups.com> wrote:
How much time do we hope to save with this change in representation?


On Wed, Apr 20, 2016 at 4:29 PM, Alexandru Moșoi <alex...@mosoi.ro>
wrote:
I submitted https://go-review.googlesource.com/#/c/21872/ which
transforms || from branching (as generated by the fronted) to just Or8. For
this was simple
because if a!=0 && b!=0 then a|b != 0. That's not true for && if a ==
2 and b == 4 for example.

I have some options:
1) Do nothing. Reasonable solution, but generates inefficient code.
2) Introduce another operations AndAnd / OrOr in generic and then
lower to ANDB and ORB. Probably too much code.
3) Transform a && b into !(!a || !b) and transform back to And8
during lowering. A bit complicated, but might be the easiest solution of
them all.

What do you think?

miercuri, 20 aprilie 2016, 16:13:37 UTC+2, Keith Randall a scris:
We may decide to extend registers differently on different
architectures. x86 has lots of support for sub-full-width operations, like
16-bit compares that ignore higher bits, so it is easiest to just let the
higher-order bits be junk. Other architectures may want to fix
higher-order bits some other way.


On Wed, Apr 20, 2016 at 7:04 AM, Alexandru Moșoi <alex...@mosoi.ro>
wrote:
Thanks. I missed that comment. That clears up the (XORBconst [1] a)
correctness.

Is there a reason why this would not generalize to other
architectures? I have to admit I have zero knowledge outside of x86 /
x86-64.



2016-04-20 15:51 GMT+02:00 Josh Bleecher Snyder <josh...@gmail.com>
:
Last time I raised this question the answer was that bools are 0
and != 0.

Keith documented here that (for SSA/amd64 at least) bools are 0
and 1:


https://github.com/golang/go/blob/master/src/cmd/compile/internal/ssa/gen/AMD64Ops.go#L13

-josh


--
Alexandru Moșoi
http://www.alexandru.mosoi.ro/

--
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.
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+...@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+...@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+...@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.
--
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

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 15 of 15 | next ›
Discussion Overview
groupgolang-dev @
categoriesgo
postedApr 20, '16 at 9:42a
activeApr 22, '16 at 2:12p
posts15
users6
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase