Consistently use a separate Lithium instruction for flooring division.

Consistently use a separate Lithium instruction for flooring division.

Previously we tried to share some code on by a slightly confusing re-use
of LDivI for a (general) flooring division. Now we cleanly separate
concerns, just like for the rest of the division-like operations. Note
that ARM64 already did it this way.

If we really want to save some code, we can introduce some macro
assembler instructions and/or helper functions in the code generator in
a future CL, but we should really try to avoid being "clever" to save
just a few lines of trivial code. Effort != complexity. :-)

Renamed some related Lithium operands on the way for more consistency.

R=mstarzinger@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=20395

[Sven Panne, 2014-03-26 11:26:18]

Flushing my queue of local branches... :-) Note that this CL is mostly
mechanical.

[Michael Starzinger, 2014-03-26 15:49:40]

I am not yet entirely convinced that this change actually improves the situation
overall. Admittedly it removes one of the "if (do_something_different) { ... }"
branches in the lithium code generator. But that comes at the expense of
duplicating 40 lines of code in each code generator. And they are separated far
enough that I can totally imagine my stupid-future-self updating one instance
but not the other.

I do +1 the part that introduces a separate LInstruction for the flooring
division, this makes the distinction in semantics clear in the lithium graph.

I would be totally fine with this change if the common code in the generator
would still be shared. For example by using a helper function or support from
the macro assembler, as you mentioned yourself in the CL description.

[Sven Panne, 2014-03-27 08:05:07]

On 2014/03/26 15:49:40, Michael Starzinger wrote:
> I am not yet entirely convinced that this change actually improves the
situation
> overall. Admittedly it removes one of the "if (do_something_different) { ...
}"
> branches in the lithium code generator. But that comes at the expense of
> duplicating 40 lines of code in each code generator. And they are separated
far
> enough that I can totally imagine my stupid-future-self updating one instance
> but not the other.

This actually improves the situation *a lot*: With this CL things are now highly
consistent across platform. We have 3 division-like operations on the Hydrogen
level, which are consistently lowered to 3 Lithium variants each (power of 2
constant, other constant, general case) with this CL. Without that CL, 3
platforms behave differently, trying so save a few dozen lines of simple code
(yes, partly duplicated code, but that's a *totally* different story). So in
effect we're trading some tiny simplification for various "WTF?" moments when
reading the code, which is quite bad IMHO.

> I do +1 the part that introduces a separate LInstruction for the flooring
> division, this makes the distinction in semantics clear in the lithium graph.

:-)

> I would be totally fine with this change if the common code in the generator
> would still be shared. For example by using a helper function or support from
> the macro assembler, as you mentioned yourself in the CL description.

Perhaps my initial comment about this CL was not clear enough: I totally agree
the common CS folklore that redundancy is the root of all evil, but in our case
fixing things is a 2-step process: First we have to get the structure right
(this CL), and then (and only then) see what can be abstracted out. We literally
have *thousands* of lines of copy-n-paste code in each backend, and I'm totally
willing to clean a few things related to this CL up in a follow-up CL. But this
will very probably touch non LFlooringDiv*-related stuff and therefore would
totally hide the intent and simplicity of this CL at hand.

In a nutshell: I really, really like to land this CL, we (= I? :-) can then have
a *global* look at the backends to see what can be abstracted out. I hate our
approach of fixing/"improving" things only locally, which normally leaves a
bigger mess behind than before.

[Sven Panne, 2014-04-01 09:51:46]

As discussed offline, I added a few TODOs to make it clear that we somehow need
to clean up the code duplication in the code generators.

[Michael Starzinger, 2014-04-01 11:23:11]

LGTM.

After our offline discussion I am fine with having this intermediate step that
just splits out the LInstructions, as long as the duplication is dealt with
later on (as the TODOs ensure). Thanks.

[Sven Panne, 2014-04-01 11:42:53]

Committed patchset #2 manually as r20395 (presubmit successful).