Introduce a stripped down version of UseScratchRegisterScope for ARM and use it
inside the assembler and macro-assembler. At the exception of the Call
instructions, we now use this scope instead of using the ip register
directly. This is inspired from how the ARM64 backend works.
In general, the benefit of doing this is we can catch cases where ip is being
used both by the caller and by the assembler. But more specifically, TurboFan
reserves r9 as an extra scratch register because ip can already be used by the
assembler. With this utility, we can isolate the cases in the code generator
which need an extra register and potentially fix them, allowing us to give r9
back to the register allocator.
This patch uncovered places in the assembler where we were using ip
unconditionally when we could have re-used the destination register instead.
Bug: v8:6553
Change-Id: Ib7134e3ed64dd1f90baf209ae831ed8f644cac78
Reviewed-on: https://chromium-review.googlesource.com/544956
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46425}
On x86, signalling NaNs get converted to quiet NaNs when they get push
on the stack and popped again. This happens in the code generation for
arm, specifically for the vmov instruction with the immediate parameter.
This CL replaces the vmov function in assembler-arm to take the
immediate as a uint64_t instead of a double, to guarantee that the bit
pattern does not change even if the parameter is a signalling NaN.
BUG=v8:6564
Change-Id: I062559f9a7ba8b0f560628e5c39621ca578c3e7d
Reviewed-on: https://chromium-review.googlesource.com/558964
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#46418}
Instead of allocating and embedding certain heap numbers into the code
during code assembly, emit dummies but record the allocation requests.
Later then, in Assembler::GetCode, allocate the heap numbers and patch
the code by replacing the dummies with the actual objects. The
RelocInfos for the embedded objects are already recorded correctly when
emitting the dummies.
R=jarin@chromium.org
BUG=v8:6048
Review-Url: https://codereview.chromium.org/2900683002
Cr-Commit-Position: refs/heads/master@{#45635}
- Adds new F32x4AddHoriz, I32x4AddHoriz, etc. to WASM opcodes.
- Implements them for ARM.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2804883008
Cr-Commit-Position: refs/heads/master@{#44812}
- Implements vuzp, vtrn instructions for q-registers.
- Refactors vmvn, vswp to use common unary op helper fn.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2739033002
Cr-Commit-Position: refs/heads/master@{#43795}
- Implements Select instructions using a single ARM vbsl instruction.
- Renames boolean machine operators to match renamed S1xN machine types.
- Implements S1xN vector logical ops, AND, OR, XOR, NOT for ARM.
- Implements S1xN AnyTrue, AllTrue ops for ARM.
- Eliminates unused SIMD op categories in opcodes.h.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2711863002
Cr-Commit-Position: refs/heads/master@{#43556}
The x64 side is included in https://chromium-review.googlesource.com/c/444226/
BUG=v8:5294
Change-Id: Ie255604c5e38c72e3c2b76e1ca3557a5fde108ee
Reviewed-on: https://chromium-review.googlesource.com/446394
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43481}
- Adds vqadd.s/u, vqsub.s/u for all integer lane sizes.
- Refactors disassembler and simulator, using switches instead
of long if-else chains.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2649323012
Cr-Commit-Position: refs/heads/master@{#42865}
- Adds vmin, vmax for FP and integer vectors, both signed and unsigned.
- Regularizes switching logic in disasm and simulator for special codes
4 and 6.
- Factors vrecpe, vrsqrte, vrecps, vrsqrts into helper fns.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2623993006
Cr-Commit-Position: refs/heads/master@{#42385}
The simulator implements these exactly, but on ARM hardware,
the estimates are not exact, so CHECK_EQ will fail. This CL adds
a tolerance to the checks.
LOG=N
BUG=v8:4124
Review-Url: https://codereview.chromium.org/2628153003
Cr-Commit-Position: refs/heads/master@{#42320}
Attempt to fix or get insight into failing vswp test on V8 ARM bot.
LOG=N
BUG=
Review-Url: https://codereview.chromium.org/2539533005
Cr-Commit-Position: refs/heads/master@{#41397}
CpuFeatures::IsSupported(feature) indicates that the feature is
available on the target. AssemblerBase::IsEnabled(feature) indicates
that we've checked for support (using CpuFeatureScope). The main benefit
is that we can test on (for example) ARMv8, but have some assurance that
we won't generate ARMv8 instructions on ARMv7 targets.
This patch simply cleans up the usage, which had become inconsistent.
The instruction emission functions now check not only that their
dependent features are supported, but also that we've verified that
using CpuFeatureScope.
BUG=
Review-Url: https://codereview.chromium.org/2360243002
Cr-Commit-Position: refs/heads/master@{#39676}
The test was using some callee saved registers but tests don't save those.
BUG=v8:5354
Review-Url: https://codereview.chromium.org/2322923002
Cr-Commit-Position: refs/heads/master@{#39275}
Reason for revert:
Breaks g++ build.
Original issue's description:
> [turbofan] ARM: Implement vswp and use in gap resolver
>
> Use vswp to switch double-precision registers in the gap resolver, with fall
> back temp register-based code if NEON is not available.
>
> BUG=
>
> Committed: https://crrev.com/2837c2e65a2ee5b9fc610f30ce1215f52323ecbd
> Cr-Commit-Position: refs/heads/master@{#39209}
BUG=
Review-Url: https://codereview.chromium.org/2314043002
Cr-Commit-Position: refs/heads/master@{#39264}
Use vswp to switch double-precision registers in the gap resolver, with fall
back temp register-based code if NEON is not available.
BUG=
Review-Url: https://codereview.chromium.org/2313803003
Cr-Commit-Position: refs/heads/master@{#39209}
ARMv8 can use vminnm and vmaxnm to handle most inputs. Other platforms
use an implementation similar to what was there before, except that
out-of-line code is used for the uncommon cases.
BUG=
Review-Url: https://codereview.chromium.org/2313863003
Cr-Commit-Position: refs/heads/master@{#39202}
These are ARMv8 instructions that will be used in a follow-up patch.
BUG=
Review-Url: https://codereview.chromium.org/2273003002
Cr-Commit-Position: refs/heads/master@{#39193}
All supported ARM targets support unaligned accesses for integer
accesses. This patch removes the remnants of support for older targets.
BUG=v8:5077
Review-Url: https://codereview.chromium.org/2184823002
Cr-Commit-Position: refs/heads/master@{#38099}
The usat instruction is available from ARMv6, so there's no need to
check for the ARMv7 feature before using it. ARMv6 is the oldest
supported architecture in V8.
Correcting this allows the removal of a special case for predictable
code size.
BUG=
Review-Url: https://codereview.chromium.org/1974903002
Cr-Commit-Position: refs/heads/master@{#36218}
Reduce the amount of code generated for OutOfLineLoadFloat* by computing
sqrt(-1) rather than move the NaN as an immediate. Add support for single
precision floating point immediate moves to enable this.
BUG=
Review URL: https://codereview.chromium.org/1758003003
Cr-Commit-Position: refs/heads/master@{#34746}
Only CPSR_f is supported, and then only for the flags that we actually
simulate (NZCV). This isn't currently used, but will be useful for some
tests.
BUG=
Review URL: https://codereview.chromium.org/1776933003
Cr-Commit-Position: refs/heads/master@{#34662}
The test expectations should fail consistently in both release and debug
builds. DCHECK is only meant for debug-only checks in production code.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1506753002
Cr-Commit-Position: refs/heads/master@{#32639}
The Float32RoundTruncate operator rounds float32 numbers towards zero.
The operator is currently implemented on x64, ia32, arm, and arm64.
Additionally I added support for the float32 vrintz, vrintn, and vrinta
instructions to the arm simulator.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1468303005
Cr-Commit-Position: refs/heads/master@{#32301}
Without that, it has a few false positives about out-of-bounds array accesses.
Also makes the clang static-analyzer happy.
Original code review from Sven Panne:
https://codereview.chromium.org/790723002/
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_arm_dbg,v8_linux_arm64_dbg,v8_mac64_dbg,v8_win_compile_dbg,v8_linux_gcc_rel
Review URL: https://codereview.chromium.org/1393023003
Cr-Commit-Position: refs/heads/master@{#31185}
Reason for revert:
Breaks Arm debug.
Original issue's description:
> Reland: Introduce a V8_NORETURN macro and use it to make GCC 4.9.2 happy again.
>
> Without that, it has a few false positives about out-of-bounds array accesses.
> Also makes the clang static-analyzer happy.
>
> Original code review from Sven Panne:
> https://codereview.chromium.org/790723002/
>
> CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_arm_dbg,v8_linux_arm64_dbg,v8_mac64_dbg,v8_win_compile_dbg
>
> Committed: https://crrev.com/93ae81101af68d81b7af84ea4046ea849e605116
> Cr-Commit-Position: refs/heads/master@{#31163}
TBR=jochen@chromium.org,karl@skomski.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1398643002
Cr-Commit-Position: refs/heads/master@{#31167}
Without that, it has a few false positives about out-of-bounds array accesses.
Also makes the clang static-analyzer happy.
Original code review from Sven Panne:
https://codereview.chromium.org/790723002/
CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_arm_dbg,v8_linux_arm64_dbg,v8_mac64_dbg,v8_win_compile_dbg
Review URL: https://codereview.chromium.org/1383053005
Cr-Commit-Position: refs/heads/master@{#31163}
This basically means that we must not use the b(Label*) version here,
but the b(int) version instead to jump over the constant pool.
BUG=v8:4292
LOG=y
Review URL: https://codereview.chromium.org/1224243002
Cr-Commit-Position: refs/heads/master@{#29552}
The b, bl and blx methods that take labels basically ignore the constant
pool check and just block the constant pool for the next instruction.
This way a long enough sequence of those instructions will block can
potentially block the constant pool emission for too long.
BUG=v8:4292
LOG=y
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1223093004
Cr-Commit-Position: refs/heads/master@{#29550}
The remaining uses need some non-mechanical work:
* non-standard-layout type, probably due to mixed access control
* extended field designators
Review URL: https://codereview.chromium.org/1173343006
Cr-Commit-Position: refs/heads/master@{#29071}
Performance measurements show that the position independent code is
usually slightly faster than the position dependent code, and there
seems to be no noticable regression.
This also gets rid of a lot of support code that was only required to allow
embedding labels into the code stream. And it implies that neither the GC
nor the deserializer need to do anything for jump tables.
R=svenpanne@chromium.org
BUG=v8:3872
LOG=n
Review URL: https://codereview.chromium.org/1069633002
Cr-Commit-Position: refs/heads/master@{#27646}
The (32 - fraction_bits) value should be encoded so that the least
significant bit is set to bit 5 and the four next bits to bits 0-3. Fix
the previously incorrect encoding. This bug did not cause behavioral
issues before, since in existing uses of the function the order of the
bits in the immediate value does not matter, as they are all 1.
BUG=3256
LOG=N
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/223623003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20508 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The first jump to a specific label was marked as jump to absolute
position -4. This value was stored in the assembly as a branch to a
offset (-4 - (instruction offset + 8)). The offset is only 24 bit
long on ARM. Thus instruction offsets higher than 2^23 - 12 would overflow
the offset.
Fix by denoting the first jump to a label by storing the jump
instruction location as the target. This will result in offset of -8,
which of course always fits in the branch instruction.
BUG=2736
TEST=cctest/test-assembler-arm/17
R=bmeurer@chromium.org, svenpanne@chromium.org
Review URL: https://codereview.chromium.org/17116006
Patch from Kimmo Kinnunen <kkinnunen@nvidia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@15997 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Refactoring:
* consistent use of SmiTag/Untag
* added a few Smi macros and helpers
Improvements
* small optimisations (e.g. merging untag and cmp #0)
* added fixed point to double conversion instructions for simpler conversions
More on the last point: a Smi can be seen as a fixed point number with the
a one bit fractional part. Fixed to double instructions allow us to convert
a Smi to a double without untagging.
BUG=none
TEST=none
Review URL: https://chromiumcodereview.appspot.com/15085026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14724 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
I tried to limit the use of v8::Isolate::GetCurrent() and v8::internal::Isolate::Current() as much as possible, but sometimes this would have involved restructuring tests quite a bit, which is better left for a separate CL.
BUG=v8:2487
Review URL: https://codereview.chromium.org/12716010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13953 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
First of all, it has nothing to do with Isolates, it is related to the assembler
at hand. Furthermore, the saving/restoring is platform-independent. Cleaned up
some platform-specific stuff on the way.
Note that there are some things which still need some cleanup, like e.g. using
EnumSet instead of uint64_t, making Probe() more uniform across platforms etc.,
but the CL is already big enough.
BUG=v8:2487
Review URL: https://codereview.chromium.org/12391055
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13823 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Unified parameter order of CreateHandle with the rest of v8 on the way. A few
Isolate::Current()s had to be introduced, which is not nice, and not every place
will win a beauty contest, but we can clean this up later easily in smaller steps.
Review URL: https://codereview.chromium.org/12300018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13717 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The assembler has 8 different vmov variants. The one for vmov.32 and for moving
an immediate into a double reg only differs in the type of the second
paremeter: vmov.32 takes an int, the other takes a double.
The situation is dangerous because C++ will happily implicitly convert between
int and double.
This patch changes the signature of the vmov.32 assembler function so that it
cannot be confused with the other vmovs.
BUG=none
Review URL: https://chromiumcodereview.appspot.com/12255031
Patch from Hans Wennborg <hans@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13668 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The ARM and MIPS assemblers had a bug where they did not handle the last element
in the list of code positions correctly during the fixup of offsets for forward
jumps. This happened when the first instruction contained a forward jump to a
label, and that label was used in a forward jump later, too.
Unified the code for Assembler::next on ARM and MIPS while we were there.
Added test cases, even for ia32/x64, which seem to be correct, even I don't
fully understand why... %-}
BUG=v8:1644
Review URL: http://codereview.chromium.org/7786001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9063 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
