Looks good from my side.
Benedikt?
https://codereview.chromium.org/601723002/diff/20001/src/compiler/mips/code-generator-mips.cc
File src/compiler/mips/code-generator-mips.cc (right):
https://codereview.chromium.org/601723002/diff/20001/src/compiler/mips/code-generator-mips.cc#newcode170
src/compiler/mips/code-generator-mips.cc:170: i.InputOperand(1),
kCompareReg, kScratchReg);
On 2014/09/25 17:18:39, paul.l... wrote:
On 2014/09/24 15:23:31, titzer wrote:
> The macro assembler methods here generate a lot of instructions. It
may not be
> an overall win to generate an add with overflow on MIPS, but instead
to
generate
> an explicit tag check with a branch and a regular add.
Yes, Overflow checking is an issue for MIPS. We have two variations of
add/sub,
one generates TRAP on overflow[1], the other silently overflows. We
use the
silent version, but must generate extra instructions to check. I don't
understand your suggestion "generate an explicit tag check with a
branch and a
regular add", can you elaborate?
I meant in the front end, when we lower a v8 representation change (i.e.
convert a tagged number to a machine int32 or vice versa). If
AddWithOverflow isn't very efficient on a particular backend, we can
generate a different set of machine operators. That's something where
the backend should be able to configure the frontend to avoid expensive
operations.
The new MIPS r6 instruction set gives us a new/faster way to detect
overflows,
we will implement that soon, but still need the old way for older
cores.
Ok, that is more reason to have the backend configure the frontend to
avoid certain operations that are complex/slow on specific generations
of an architecture.
[1] I prototyped with the TRAP version a year ago, and it made a nice
speed
improvement on some benchmarks, but I thought it best to avoid
installing signal
handler, it could be fragile, and maybe problematic with sandboxing.
Agree. And it could also be very slow for certain programs.
https://codereview.chromium.org/601723002/diff/20001/src/compiler/mips/code-generator-mips.cc#newcode361
src/compiler/mips/code-generator-mips.cc:361: FlagsCondition condition)
{
On 2014/09/25 17:18:39, paul.l... wrote:
Complications arise from MIPS not having condition codes like other
arch's. The
compare and branch are merged into a single instruction, which means
that the
branch instruction needs the registers provided to the compare to
still be
valid. The current FlagsContinuation mechanism does guarantee this. As
you can
see we mostly don't emit instructions for the compare itself, but we
do preserve
the type of comparison as a psuedo-op to guide the branch generation.
> The handling of branches here is tough to follow.
Yes, the code is a bit ugly :( It "looked better" here with
single-line cases:
https://github.com/paul99/v8m-rb/blob/b8e8df9/src/compiler/mips/code-generator-mips.cc#L403
but clang-format won't take that form. I'm thinking of splitting into
4 smaller
routines, each specialized for one arch_opcode type. I'd be glad to
hear your
ideas.
Another issue is the exposed branch delay slots here, which make
things faster
at the expense of readability.
Ok, in that case maybe using a FlagsContinuation on MIPS is more trouble
than its worth, and the instruction selector could just emit specific
kinds of compare instructions and not try to combine the flags usage
with arithmetic (which is our goal on x86).
But that's something we can iterate on; I'm ok with landing this as is.
https://codereview.chromium.org/601723002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
