Skip to content

V
V8
Switch branch/tag
  1. 18 Jun, 2018 1 commit
  3. 08 Jun, 2018 1 commit
  5. 04 Jun, 2018 2 commits
  7. 25 May, 2018 1 commit
  9. 14 Apr, 2018 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored 
      The "Address" type is V8's general-purpose type for manipulating memory
addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
are undefined behavior except within the same array; since we generally
don't operate within a C++ array, our general-purpose type shouldn't be
a pointer type.

Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
Reviewed-on: https://chromium-review.googlesource.com/988657
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  11. 05 Apr, 2018 1 commit
    • jgruber's avatar
      Rename Code::instruction_{start,end,size} functions · 7b29fe43
      jgruber authored 
      In order to clarify the difference between, e.g., InstructionStart and
instruction_start, rename as follows:

Code::instruction_start -> raw_instruction_start
Code::instruction_end   -> raw_instruction_end
Code::instruction_size  -> raw_instruction_size

The difference between the camel-case and raw_* function families is
in how they handle off-heap-trampoline Code objects. For example, when
called on an off-heap-trampoline: raw_instruction_start returns the
trampoline's entry point, while InstructionStart returns the off-heap
code's entry point (located in the .text section of the binary).

Some callsites were updated to call the camel-case function family as
appropriate.

Bug: v8:6666
Change-Id: I4a572f47c2d161a853599d7c17879e263b0d1a87
Reviewed-on: https://chromium-review.googlesource.com/997532
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52387}
      7b29fe43
  13. 22 Mar, 2018 1 commit
  15. 13 Mar, 2018 1 commit
  17. 26 Feb, 2018 1 commit
  19. 21 Feb, 2018 1 commit
  21. 13 Feb, 2018 1 commit
  23. 09 Feb, 2018 2 commits
  25. 02 Feb, 2018 1 commit
    • Pierre Langlois's avatar
      [arm] Introduce UseScratchRegisterScope for VFP registers · 610a3610
      Pierre Langlois authored 
      Replace hard-coded uses of `kScratchDoubleReg`, `kScratchDoubleReg2` and
`kScratchQuadReg` with the safer `UseScratchRegisterScope`. The reason for doing
this is to be able to safely use these scratch registers inside the assembler
without having to worry about the code generator using them too.

For instance, using this scope showed us that `TryInlineTruncateDoubleToI` is
using a FP scratch register while the caller, the `DoubleToI` stub, is using it
too. We are safe only because the stub passes the scratch register to
`TryInlineTruncateDoubleToI` as an input. Using the scope forces us to
explicitely use the input register instead of acquiring a new scratch.

Bug: v8:6553
Change-Id: I84c53cd851d31ea33b0e3ef398d7a858b7e3e3c4
Reviewed-on: https://chromium-review.googlesource.com/895460Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#51061}
      610a3610
  27. 22 Jan, 2018 1 commit
  29. 16 Jan, 2018 1 commit
  31. 10 Jan, 2018 1 commit
    • Pierre Langlois's avatar
      [arm] Restrict usage of pc-relative LDR. · 5361c57b
      Pierre Langlois authored 
      Disallow using the PC as a base in LDR and instead provide a dedicated assembler
method for pc-relative loads. The reason for this is that the generic
`Assembler::ldr` method may decide to generate more instructions if the offset
is out of range, and if the PC was the base, we would get surprising
results. For example:

~~~
ldr r0, [pc, #0xcabba9e]
~~~

is not equivalent to:

~~~
movw ip, #0xba9e
movt ip, #0xcab
ldr r0, [pc, ip]
~~~

since the reference to the PC has moved down two instructions!

We could teach the assembler to handle those cases correctly, but pc-relative
loads are used in specific cases only so that's not necessary.

As a drive-by, remove a reference to code aging.

Bug: 
Change-Id: I586d83a418db52cf28d3b524f889bf40f077998a
Reviewed-on: https://chromium-review.googlesource.com/847008Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#50475}
      5361c57b
  33. 19 Dec, 2017 1 commit
  35. 04 Dec, 2017 1 commit
  37. 02 Dec, 2017 1 commit
    • Mathias Bynens's avatar
      Normalize casing of hexadecimal digits · 822be9b2
      Mathias Bynens authored 
      This patch normalizes the casing of hexadecimal digits in escape
sequences of the form `\xNN` and integer literals of the form
`0xNNNN`.

Previously, the V8 code base used an inconsistent mixture of uppercase
and lowercase.

Google’s C++ style guide uses uppercase in its examples:
https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters

Moreover, uppercase letters more clearly stand out from the lowercase
`x` (or `u`) characters at the start, as well as lowercase letters
elsewhere in strings.

BUG=v8:7109
TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
NOPRESUBMIT=true

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
Reviewed-on: https://chromium-review.googlesource.com/804294
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49810}
      822be9b2
  39. 22 Nov, 2017 1 commit
    • Clemens Hammacher's avatar
      Allow move semantics on Labels · eeb32224
      Clemens Hammacher authored 
      The Label class currently allows to be copied on all platforms except
for arm64, where it can not be copied or moved.
This allows too much though:
Copying a label even on another platform than arm64 might fail if the
label was linked already, because only one of the copies will be bound
later, and the other will fire a DCHECK error in its destructor.

This CL changes the restriction to never allow to copy construct or
assign a Label, but allow move construction and move assignment on all
platforms except arm64.
This will allow to place Labels in containers, as will be done in
Liftoff (except for arm64, where it still needs to be allocated on the
heap).

R=mstarzinger@chromium.org

Bug: v8:6600
Change-Id: Ic1234c2d233317eed6a3d537c13faed2c701fe13
Reviewed-on: https://chromium-review.googlesource.com/783190
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49570}
      eeb32224
  41. 21 Nov, 2017 1 commit
  43. 20 Nov, 2017 1 commit
    • Ben Smith's avatar
      Enforce restriction on ARM strex{b,h} instruction · 44c52f7b
      Ben Smith authored 
      The strex (Store Exclusive) instruction has the form:

    strex rd, rt, [rn]

It stores the value in register rt at the address in register rn. If the
store succeeds, then 0 is stored in rd, otherwise 1 is stored. The ARM
manual says that behavior is "unpredictable" if d == n || d == t (i.e.
those registers are aliased).

We were not checking for this behavior in the assembler or simulator,
and as a result were generating output where it occurred. This didn't
always break; the tests we run on ARM hardware run this instruction and
pass.

BUG: chromium:786168

Change-Id: I57fe3a1db406eac96eb04ef2246f6970548d3cf9
Reviewed-on: https://chromium-review.googlesource.com/777777Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49513}
      44c52f7b
  45. 18 Oct, 2017 1 commit
  47. 13 Oct, 2017 1 commit
  49. 12 Oct, 2017 1 commit
    • Pierre Langlois's avatar
      [arm] Support splitting add with immediate instructions · d5b29f43
      Pierre Langlois authored 
      When an immediate does not fit an add instruction we use a temporary register to
hold the value, using movw/movt to encode it. However, in order to remove a use
of r9 in TurboFan's code generator, we need to cope with no scratch registers
being available. That is to say that the destination and source registers are
the same, and `ip` is not available to use.

In this case, we can split an add instruction into a sequence of additions:
```
UseScratchRegisterScope temps(...);
Register my_scratch = temps.Acquire();
__ add(r0, r0, Operand(0xabcd); // add r0, r0, #0xcd
                                // add r0, r0, #0xab00
```

As a drive-by fix, make the disassembler test fail if we expected a different
number of instructions generated.

Bug: v8:6553
Change-Id: Ib7fcc765d28bccafe39257f47cd73f922c5873bf
Reviewed-on: https://chromium-review.googlesource.com/685014Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#48491}
      d5b29f43
  51. 07 Sep, 2017 1 commit
  53. 06 Sep, 2017 1 commit
    • Clemens Hammacher's avatar
      [assembler] Make Register et al. real classes · 9e995e12
      Clemens Hammacher authored 
      Up to now, each architecture defined all Register types as structs,
with lots of redundancy. An often found comment noted that they cannot
be classes due to initialization order problems. As these problems are
gone with C++11 constexpr constants, I now tried making Registers
classes again.
All register types now inherit from RegisterBase, which provides a
default set of methods and named constructors (like ::from_code,
code(), bit(), is_valid(), ...).
This design allows to guarantee an interesting property: Each register
is either valid, or it's the no_reg register. There are no other
invalid registers. This is guaranteed statically by the constexpr
constructor, and dynamically by ::from_code.

I decided to disallow the default constructor completely, so instead of
"Register reg;" you now need "Register reg = no_reg;". This makes
explicit how the Register is initialized.

I did this change to the x64, ia32, arm, arm64, mips and mips64 ports.
Overall, code got much more compact and more safe. In theory, it should
also increase performance (since the is_valid() check is simpler), but
this is probably not measurable.

R=mstarzinger@chromium.org

Change-Id: I5ccfa4050daf4e146a557970e9d37fd3d2788d4a
Reviewed-on: https://chromium-review.googlesource.com/650927Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47847}
      9e995e12
  55. 14 Aug, 2017 1 commit
  57. 11 Aug, 2017 1 commit
  59. 02 Aug, 2017 1 commit
  61. 13 Jul, 2017 1 commit
  63. 12 Jul, 2017 1 commit
  65. 10 Jul, 2017 1 commit
  67. 07 Jul, 2017 1 commit
    • Andreas Haas's avatar
      [arm] Pass float immediates to vmov as uint32_t · 08688b39
      Andreas Haas authored 
      This CL changes for floats what https://chromium-review.googlesource.com/c/558964/
changed for doubles.

Original message:
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.

New in this CL:
Although src/double.h existed already, src/float.h did not exist yet.
I created the file in this CL, and moved the classes Float32 and
Float64 there, which already existed in src/deoptimizer.h.

R=titzer@chromium.org, martyn.capewell@arm.com, v8-arm-ports@googlegroups.com

BUG=v8:6564

Change-Id: I6a3f1f154af9c8cd4bb8e7e856235d3eee5e9edd
Reviewed-on: https://chromium-review.googlesource.com/561009
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarMartyn Capewell <martyn.capewell@arm.com>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46473}
      08688b39
  69. 06 Jul, 2017 2 commits
    • Georg Neis's avatar
      Don't dereference handles in (macro-)assembler functions used by TF. · 9b3174b2
      Georg Neis authored 
      Remove all IsHeapObject/IsSmi checks from assembler and also from
the macro-assembler functions that Turbofan code generation uses.

Note for porters: In case it's unclear which macro-assembler
functions need to be modified, it may be best to wait until I
split MacroAssembler in a followup-CL, which will make that clear.

Bug: v8:6048
Change-Id: Ife0735cc6f48713c9ec493faf2dac5e553d1c06b
Reviewed-on: https://chromium-review.googlesource.com/561015
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46436}
      9b3174b2
    • Pierre Langlois's avatar
      [arm] Introduce UseScratchRegisterScope · 8e84b715
      Pierre Langlois authored 
      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: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46425}
      8e84b715
  71. 05 Jul, 2017 1 commit
  73. 28 Jun, 2017 1 commit