1. 07 May, 2019 1 commit
  2. 06 May, 2019 1 commit
  3. 29 Apr, 2019 1 commit
  4. 18 Apr, 2019 1 commit
  5. 16 Apr, 2019 1 commit
  6. 03 Apr, 2019 1 commit
  7. 25 Mar, 2019 1 commit
    • Mythri's avatar
      [lite] Allocate feedback vectors lazily · 7629afdb
      Mythri authored
      Allocate feedback vectors lazily when the function's interrupt budget has
      reached a specified threshold. This cl introduces a new field in the
      ClosureFeedbackCellArray to track the interrupt budget for allocating
      feedback vectors. Using the interrupt budget on the bytecode array could
      cause problems when there are closures across native contexts and we may
      delay allocating feedback vectors in one of them causing unexpected
      performance cliffs. In the long term we may want to remove interrupt budget
      from bytecode array and use context specific budget for tiering up decisions
      as well.
      
      Bug: v8:8394
      Change-Id: Ia8fbb71f5e8543a92f14c44aa762973da82d445c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520719
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60450}
      7629afdb
  8. 22 Mar, 2019 2 commits
    • Sigurd Schneider's avatar
      Reland "Reland "[regalloc] Introduce deferred fixed ranges"" · 85017f04
      Sigurd Schneider authored
      This is a reland of 1ca08865
      
      Original change's description:
      > Reland "[regalloc] Introduce deferred fixed ranges"
      > 
      > This is a reland of b1769313
      > 
      > Original change's description:
      > > [regalloc] Introduce deferred fixed ranges
      > > 
      > > Fixed ranges are used to express register constraints in the
      > > allocator. This change splits these fixed ranges into one for
      > > normal code and deferred code. The former are handeled as before
      > > whereas the latter are only made visible while allocating
      > > registers for deferred code.
      > > 
      > > This prevents forward looking decisions in normal code to be
      > > impacted by register constraints from deferred code.
      > > 
      > > Change-Id: I67d562bb41166194e62765d5ab051bc961054fc7
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1477742
      > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#60322}
      > 
      > Change-Id: I1a31150256eb5608db985b144aab7ea457169d0d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530810
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#60364}
      
      Change-Id: If4a956716e7e4de132f706be2c395cdfdc04ec94
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532328Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60408}
      85017f04
    • Sven Sauleau's avatar
      [wasm] fix special parameter in int64-lowering · b2de7441
      Sven Sauleau authored
      In the int64 lowering pass some parameter nodes are considered special
      and don't require any transformation. For instance the Wasm instance.
      
      With the experimental-wasm-bigint proposal, two new special parameters
      are going through the pass, this CL avoids transforming them.
      
      Change-Id: Ie99ffaff125b9ef8c56e1883aac9e18e4072fc3e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532336
      Auto-Submit: Sven Sauleau <ssauleau@igalia.com>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
      Cr-Commit-Position: refs/heads/master@{#60404}
      b2de7441
  9. 21 Mar, 2019 1 commit
    • Sigurd Schneider's avatar
      Revert "Reland "[regalloc] Introduce deferred fixed ranges"" · 21a471f2
      Sigurd Schneider authored
      This reverts commit 1ca08865.
      
      Reason for revert: Regressions across the board
      
      Original change's description:
      > Reland "[regalloc] Introduce deferred fixed ranges"
      > 
      > This is a reland of b1769313
      > 
      > Original change's description:
      > > [regalloc] Introduce deferred fixed ranges
      > > 
      > > Fixed ranges are used to express register constraints in the
      > > allocator. This change splits these fixed ranges into one for
      > > normal code and deferred code. The former are handeled as before
      > > whereas the latter are only made visible while allocating
      > > registers for deferred code.
      > > 
      > > This prevents forward looking decisions in normal code to be
      > > impacted by register constraints from deferred code.
      > > 
      > > Change-Id: I67d562bb41166194e62765d5ab051bc961054fc7
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1477742
      > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#60322}
      > 
      > Change-Id: I1a31150256eb5608db985b144aab7ea457169d0d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530810
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#60364}
      
      TBR=jarin@chromium.org,sigurds@chromium.org,herhut@chromium.org
      
      Change-Id: Id8ad6c39774e38dd67decea997e08a4c58c452ec
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532327Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60381}
      21a471f2
  10. 20 Mar, 2019 1 commit
    • Sigurd Schneider's avatar
      Reland "[regalloc] Introduce deferred fixed ranges" · 1ca08865
      Sigurd Schneider authored
      This is a reland of b1769313
      
      Original change's description:
      > [regalloc] Introduce deferred fixed ranges
      > 
      > Fixed ranges are used to express register constraints in the
      > allocator. This change splits these fixed ranges into one for
      > normal code and deferred code. The former are handeled as before
      > whereas the latter are only made visible while allocating
      > registers for deferred code.
      > 
      > This prevents forward looking decisions in normal code to be
      > impacted by register constraints from deferred code.
      > 
      > Change-Id: I67d562bb41166194e62765d5ab051bc961054fc7
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1477742
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#60322}
      
      Change-Id: I1a31150256eb5608db985b144aab7ea457169d0d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530810
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60364}
      1ca08865
  11. 19 Mar, 2019 4 commits
    • Leszek Swirski's avatar
      Revert "[regalloc] Introduce deferred fixed ranges" · 4f719cca
      Leszek Swirski authored
      This reverts commit b1769313.
      
      Reason for revert: Flag access breaks TSAN (not an issue with this
      CL as such, but we need to revert to re-open the tree).
      
      Original change's description:
      > [regalloc] Introduce deferred fixed ranges
      > 
      > Fixed ranges are used to express register constraints in the
      > allocator. This change splits these fixed ranges into one for
      > normal code and deferred code. The former are handeled as before
      > whereas the latter are only made visible while allocating
      > registers for deferred code.
      > 
      > This prevents forward looking decisions in normal code to be
      > impacted by register constraints from deferred code.
      > 
      > Change-Id: I67d562bb41166194e62765d5ab051bc961054fc7
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1477742
      > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#60322}
      
      TBR=jarin@chromium.org,sigurds@chromium.org,herhut@chromium.org
      
      Change-Id: I5675a96acf0b5e5f7d63c60a742d2971b6d0d34d
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530803Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60324}
      4f719cca
    • Stephan Herhut's avatar
      [regalloc] Introduce deferred fixed ranges · b1769313
      Stephan Herhut authored
      Fixed ranges are used to express register constraints in the
      allocator. This change splits these fixed ranges into one for
      normal code and deferred code. The former are handeled as before
      whereas the latter are only made visible while allocating
      registers for deferred code.
      
      This prevents forward looking decisions in normal code to be
      impacted by register constraints from deferred code.
      
      Change-Id: I67d562bb41166194e62765d5ab051bc961054fc7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1477742
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60322}
      b1769313
    • Benedikt Meurer's avatar
      [turbofan] Significantly improve ConsString creation performance. · d6a60a0e
      Benedikt Meurer authored
      This change significantly improves the performance of string
      concatenation in optimized code for the case where the resulting string
      is represented as a ConsString. On the relevant test cases we go from
      
        serializeNaive: 10762 ms.
        serializeClever: 7813 ms.
        serializeConcat: 10271 ms.
      
      to
      
        serializeNaive: 10278 ms.
        serializeClever: 5533 ms.
        serializeConcat: 10310 ms.
      
      which represents a 30% improvement on the "clever" benchmark, which
      tests specifically the ConsString creation performance.
      
      This was accomplished via a couple of different steps, which are briefly
      outlined here:
      
        1. The empty_string gets its own map, so that we can easily recognize
           and handle it appropriately in the TurboFan type system. This
           allows us to express (and assert) that the inputs to NewConsString
           are non-empty strings, making sure that TurboFan no longer creates
           "crippled ConsStrings" with empty left or right hand sides.
        2. Further split the existing String types in TurboFan to be able to
           distinguish between OneByte and TwoByte strings on the type system
           level. This allows us to avoid having to dynamically lookup the
           resulting ConsString map in case of ConsString creation (i.e. when
           we know that both input strings are OneByte strings or at least
           one of the input strings is TwoByte).
        3. We also introduced more finegrained feedback for the Add bytecode
           in the interpreter, having it collect feedback about ConsStrings,
           specifically ConsOneByteString and ConsTwoByteString. This feedback
           can be used by TurboFan to only inline the relevant code for what
           was seen so far. This allows us to remove the Octane/Splay specific
           magic in JSTypedLowering to detect ConsString creation, and instead
           purely rely on the feedback of what was seen so far (also making it
           possible to change the semantics of NewConsString to be a low-level
           operator, which is only introduced in SimplifiedLowering by looking
           at the input types of StringConcat).
        4. On top of the before mentioned type and interpreter changes we added
           new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and
           CheckNonEmptyTwoByteString, which perform the appropriate (dynamic)
           checks.
      
      There are several more improvements that are possible based on this, but
      since the change was already quite big, we decided not to put everything
      into the first change, but do some follow up tweaks to the type system,
      and builtin optimizations later.
      
      Tbr: mstarzinger@chromium.org
      Bug: v8:8834, v8:8931, v8:8939, v8:8951
      Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Doc: https://bit.ly/fast-string-concatenation-in-javascript
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60318}
      d6a60a0e
    • Mike Stanton's avatar
      [TurboFan] Optimize map checks with pointer compression · 97d106f4
      Mike Stanton authored
      If pointer compression is on, it makes sense to embed the map as
      a 32-bit constant, for direct comparison. No need to uncompress
      the receiver map.
      
      Bug: v8:8982
      Change-Id: I285ca4d5b49b26536873776d298e18bcbf84b23e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1518182Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60313}
      97d106f4
  12. 18 Mar, 2019 1 commit
    • Georg Neis's avatar
      [turbofan] Unify code that determines a JSCreate's map · d9221717
      Georg Neis authored
      There were four places where we did essentially the same steps in
      order to extract the initial map for inlining a JSCreate operation.
      This CL creates a function on NodeProperties for this task.
      
      As a side effect, this fixes a bug in ReduceJSCreateArray, where
      has_initial_map could get called when it wasn't permissible to do so.
      
      Notes: For simplicity, in one or two places where we used to get the
      target/newtarget constants from the types we now get them from
      HeapConstant nodes.
      
      Cosmetic change: rename "receiver_map" to the more accurate
      "root_map" in JSNativeContextSpecialization::ExtractReceiverMaps.
      
      Bug: chromium:939316
      Change-Id: I8fd9eb50993be3d839ab9b18eeea28184c53eabf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1528435
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60301}
      d9221717
  13. 12 Mar, 2019 2 commits
  14. 08 Mar, 2019 1 commit
  15. 06 Mar, 2019 1 commit
  16. 27 Feb, 2019 1 commit
  17. 26 Feb, 2019 1 commit
  18. 18 Feb, 2019 1 commit
  19. 14 Feb, 2019 1 commit
  20. 13 Feb, 2019 1 commit
  21. 12 Feb, 2019 1 commit
  22. 08 Feb, 2019 2 commits
    • Jaroslav Sevcik's avatar
      [turbofan] Introduce aborting bounds checks. · 7bb6dc0e
      Jaroslav Sevcik authored
      Instead of eliminating bounds checks based on types, we introduce
      an aborting bounds check that crashes rather than deopts.
      
      Bug: v8:8806
      Change-Id: Icbd9c4554b6ad20fe4135b8622590093679dac3f
      Reviewed-on: https://chromium-review.googlesource.com/c/1460461
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59467}
      7bb6dc0e
    • Gus Caplan's avatar
      Reland^2 "[builtins] [turbofan] Refactor Float64Pow to use single implementation" · 98453126
      Gus Caplan authored
      This is a reland of d7def900
      
      Original change's description:
      > Reland "[builtins] [turbofan] Refactor Float64Pow to use single implementation"
      >
      > This is a reland of I968a08cef6a6d49350aa79185b2c6fb856d15f23
      >
      > Original change's description:
      > > [builtins] [turbofan] Refactor Float64Pow to use single implementation
      > >
      > > Remove platform-specific Float64Pow implementations and utils Pow in
      > > favor of a base::ieee754::pow implementation.
      > >
      > > This unifies the implementation of pow for the compiler, wasm, and
      > > runtime.
      > >
      > > Bug: v8:5848, v8:5086
      > > Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
      > > Reviewed-on: https://chromium-review.googlesource.com/c/1403018
      > > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#59229}
      >
      > Bug: v8:5848, v8:5086
      > Change-Id: I92f22ae03adafd9ad042e8d4bb406cbd5b5fb51e
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
      > Reviewed-on: https://chromium-review.googlesource.com/c/1447854
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59411}
      
      Tbr: neis@chromium.org, bmeurer@chromium.org, jkummerow@chromium.org
      Bug: v8:5848, v8:5086
      Change-Id: I42972b29b8830ed47a00b2b1d408d3005a810c0e
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/1456302Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59454}
      98453126
  23. 06 Feb, 2019 2 commits
    • Sigurd Schneider's avatar
      Revert "Reland "[builtins] [turbofan] Refactor Float64Pow to use single implementation"" · d691fde3
      Sigurd Schneider authored
      This reverts commit d7def900.
      
      Reason for revert: Breaks UBSan:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20UBSan/4542
      
      Besides undefined behavior, things were looking good!
      
      
      Original change's description:
      > Reland "[builtins] [turbofan] Refactor Float64Pow to use single implementation"
      > 
      > This is a reland of I968a08cef6a6d49350aa79185b2c6fb856d15f23
      > 
      > Original change's description:
      > > [builtins] [turbofan] Refactor Float64Pow to use single implementation
      > >
      > > Remove platform-specific Float64Pow implementations and utils Pow in
      > > favor of a base::ieee754::pow implementation.
      > >
      > > This unifies the implementation of pow for the compiler, wasm, and
      > > runtime.
      > >
      > > Bug: v8:5848, v8:5086
      > > Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
      > > Reviewed-on: https://chromium-review.googlesource.com/c/1403018
      > > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#59229}
      > 
      > Bug: v8:5848, v8:5086
      > Change-Id: I92f22ae03adafd9ad042e8d4bb406cbd5b5fb51e
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
      > Reviewed-on: https://chromium-review.googlesource.com/c/1447854
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59411}
      
      TBR=jkummerow@chromium.org,jarin@chromium.org,neis@chromium.org,jgruber@chromium.org,clemensh@chromium.org,bmeurer@chromium.org,me@gus.host
      
      Change-Id: I65c4bbd3ab7aaa1c396d182467c5a1fe6a639df5
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:5848, v8:5086
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/1456107Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59419}
      d691fde3
    • Gus Caplan's avatar
      Reland "[builtins] [turbofan] Refactor Float64Pow to use single implementation" · d7def900
      Gus Caplan authored
      This is a reland of I968a08cef6a6d49350aa79185b2c6fb856d15f23
      
      Original change's description:
      > [builtins] [turbofan] Refactor Float64Pow to use single implementation
      >
      > Remove platform-specific Float64Pow implementations and utils Pow in
      > favor of a base::ieee754::pow implementation.
      >
      > This unifies the implementation of pow for the compiler, wasm, and
      > runtime.
      >
      > Bug: v8:5848, v8:5086
      > Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
      > Reviewed-on: https://chromium-review.googlesource.com/c/1403018
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59229}
      
      Bug: v8:5848, v8:5086
      Change-Id: I92f22ae03adafd9ad042e8d4bb406cbd5b5fb51e
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/1447854
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59411}
      d7def900
  24. 31 Jan, 2019 2 commits
  25. 28 Jan, 2019 1 commit
  26. 25 Jan, 2019 1 commit
  27. 14 Jan, 2019 1 commit
  28. 11 Jan, 2019 1 commit
  29. 10 Jan, 2019 1 commit
  30. 09 Jan, 2019 1 commit
  31. 17 Dec, 2018 1 commit
  32. 13 Dec, 2018 1 commit