- 01 Feb, 2019 1 commit
-
-
Clemens Hammacher authored
This CL changes the usage pattern from FOR_XXX_VALUES(i) { Use(*i); } to FOR_XXX_VALUES(i) { Use(i); } which is way more intuitive. Note that the replacement in the uses was done via regular expression, so it's purely mechanical. In two locations I removed unneeded braces around the macro, because they confused clang-format. I plan to do more cleanups (remove redundant assignments within the FOR_XXX_VALUES body) in a follow-up CL. R=mstarzinger@chromium.org Bug: v8:8562 Change-Id: I4329bfcf34e5b077d19b50f4204ceb3b4340fe61 Reviewed-on: https://chromium-review.googlesource.com/c/1449615 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#59287}
-
- 20 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
Merging the temporary HeapObjectPtr back into HeapObject. Bug: v8:3770 Change-Id: I5bcd23ca2f5ba862cf5b52955dca143e531c637b Reviewed-on: https://chromium-review.googlesource.com/c/1386492 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58410}
-
- 27 Sep, 2018 1 commit
-
-
Vasili Skurydzin authored
test/cctest/compiler/value-helper.h: fix due to a GCC bug affecting padding of aggregate data types on Aix. GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61976 Change-Id: I303b09a9a84b372033c16cbf157d5fc2bf25f93a Reviewed-on: https://chromium-review.googlesource.com/1244616Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#56274}
-
- 11 Sep, 2018 1 commit
-
-
Clemens Hammacher authored
In the CHECK_FLOAT_EQ and CHECK_DOUBLE_EQ wrappers, do also print hex representations on failure. Otherwise, single bit flips might not be visible in the output, like here: Check failed: DoubleWrapper(x) == y (-2e+66 vs. -2e+66). R=titzer@chromium.org Change-Id: I2521706aedc6ff81c0dbb25259230f8e29ce9a3e Reviewed-on: https://chromium-review.googlesource.com/1219630Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#55799}
-
- 27 Jun, 2018 1 commit
-
-
Michael Starzinger authored
This fixes include violations where normal "foo.h" headers included inline "bar-inl.h" headers. It also removes two (almost) dead methods. R=clemensh@chromium.org BUG=v8:7754 Change-Id: I11c6ce71650db22f3c1d7cf5ca50529c94b94839 Reviewed-on: https://chromium-review.googlesource.com/1117076 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54060}
-
- 27 Apr, 2018 1 commit
-
-
Clemens Hammacher authored
Both macros currently call a function with individual CHECKs, which makes error messages only show that one part of the equality check (and not the the actual float values), and hides the actual location of the check. This CL refactors this such that the actual value is shown (just as with other CHECK_EQ macros) and it shows the right file name and line number. R=ahaas@chromium.org Bug: v8:7570 Change-Id: I198e73c053178a09f14330a18069463760693f81 Reviewed-on: https://chromium-review.googlesource.com/1027879Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#52832}
-
- 05 Mar, 2018 2 commits
-
-
Sigurd Schneider authored
Bug: v8:7517, v8:7310 Change-Id: Ic9a1ac8f4a928e1d5d8f807a0875c7314a7777fb Reviewed-on: https://chromium-review.googlesource.com/946095 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51735}
-
Sigurd Schneider authored
This also introduces FrameStateInfoOf helper. Bug: v8:7517, v8:7310 Change-Id: If2dd1257fb9384fe957a980077a65154cc014d3b Reviewed-on: https://chromium-review.googlesource.com/946009 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#51718}
-
- 02 Dec, 2017 1 commit
-
-
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: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#49810}
-
- 20 Oct, 2017 1 commit
-
-
Clemens Hammacher authored
This is a reland of 6f93d59d. One more test had to be disabled (tracked by bug 6954), and two machops tests needed to be changed to use boxed floats and doubles. Original change's description: > [test] Add nan bit patterns to uint{32,64}_vector > > If you just cast those patterns to float or double and pass them > around, the quiet/signaling NaN bit might change. We had several bugs > around this, so add these patterns to the general input vectors. > > This uncovers a bug in the wasm interpreter, which will be fixed in a > separate CL. > > R=ahaas@chromium.org > > Bug: v8:6947, v8:6954 > Change-Id: I205b8ab784b087b1e4988190fa725df0b90e7ee0 > Reviewed-on: https://chromium-review.googlesource.com/725345 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48731} Bug: v8:6947, v8:6954 Change-Id: I9a38b5d9324131c3950c537910371a73c93d2c13 Reviewed-on: https://chromium-review.googlesource.com/728439Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48780}
-
- 19 Oct, 2017 3 commits
-
-
Michael Achenbach authored
This reverts commit 6f93d59d. Reason for revert: Breaks full-debug build: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20full%20debug/builds/2239 Original change's description: > [test] Add nan bit patterns to uint{32,64}_vector > > If you just cast those patterns to float or double and pass them > around, the quiet/signaling NaN bit might change. We had several bugs > around this, so add these patterns to the general input vectors. > > This oncovers a bug in the wasm interpreter, which will be fixed in a > separate CL. > > R=ahaas@chromium.org > > Bug: v8:6947, v8:6954 > Change-Id: I205b8ab784b087b1e4988190fa725df0b90e7ee0 > Reviewed-on: https://chromium-review.googlesource.com/725345 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48731} TBR=ahaas@chromium.org,clemensh@chromium.org Change-Id: I4ceb82eab5d4cbf1f335bf6f358178a17a2fd0ba No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6947, v8:6954 Reviewed-on: https://chromium-review.googlesource.com/728101Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#48745}
-
Clemens Hammacher authored
If you just cast those patterns to float or double and pass them around, the quiet/signaling NaN bit might change. We had several bugs around this, so add these patterns to the general input vectors. This oncovers a bug in the wasm interpreter, which will be fixed in a separate CL. R=ahaas@chromium.org Bug: v8:6947, v8:6954 Change-Id: I205b8ab784b087b1e4988190fa725df0b90e7ee0 Reviewed-on: https://chromium-review.googlesource.com/725345 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#48731}
-
Clemens Hammacher authored
This is a reland of e737b4ce. The issue on windows bots was fixed in https://crrev.com/c/725733. Original change's description: > [test] Avoid unnecessary std::vector allocations > > Instead of copying an array of fixed values into an std::vector for > each usage of the FOR_INPUTS macro, just iterate the constant data > directly. > This also makes the <type>_vector() functions return {constexpr Vector} > instead of {std::vector}. > > R=tebbi@chromium.org > > Change-Id: Ifc3e5509b2fbf5e383c967c2f46acf2b07f7b5b4 > Reviewed-on: https://chromium-review.googlesource.com/725427 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48688} Change-Id: I9ad5d22803bbbf35c458965497acc603cfa01b20 Reviewed-on: https://chromium-review.googlesource.com/725979Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48726}
-
- 18 Oct, 2017 2 commits
-
-
Clemens Hammacher authored
This reverts commit e737b4ce. Reason for revert: On windows, V8_INFINITY is not constexpr Original change's description: > [test] Avoid unnecessary std::vector allocations > > Instead of copying an array of fixed values into an std::vector for > each usage of the FOR_INPUTS macro, just iterate the constant data > directly. > This also makes the <type>_vector() functions return {constexpr Vector} > instead of {std::vector}. > > R=tebbi@chromium.org > > Change-Id: Ifc3e5509b2fbf5e383c967c2f46acf2b07f7b5b4 > Reviewed-on: https://chromium-review.googlesource.com/725427 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48688} TBR=clemensh@chromium.org,tebbi@chromium.org Change-Id: Iccb52941d4efe71b49b41572c3d922a5d78bdfd2 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/725899Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48691}
-
Clemens Hammacher authored
Instead of copying an array of fixed values into an std::vector for each usage of the FOR_INPUTS macro, just iterate the constant data directly. This also makes the <type>_vector() functions return {constexpr Vector} instead of {std::vector}. R=tebbi@chromium.org Change-Id: Ifc3e5509b2fbf5e383c967c2f46acf2b07f7b5b4 Reviewed-on: https://chromium-review.googlesource.com/725427Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48688}
-
- 01 Sep, 2017 1 commit
-
-
Clemens Hammacher authored
This required splitting wasm-run-utils.h in header and implementation, since the anonymous namespace in wasm-run-utils.h is now gone. This is a reasonable refactoring in itself. R=titzer@chromium.org CC=mstarzinger@chromium.org, mostynb@opera.com Bug: chromium:746958 Change-Id: I0f3b30fef1865cd88eca37b69d0c3a9eb19e77ea Reviewed-on: https://chromium-review.googlesource.com/647587Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47773}
-
- 02 Aug, 2017 1 commit
-
-
Deepti Gandluri authored
- Decode logic for atomic operations - Implementations for I32AtomicAdd, I32AtomicAdd8U, I32AtomicAdd16U, I32AtomicSub, I32AtomicSub8U, I32AtomicSub16U - cctest value helpers for Uint16/Uint8 types R=binji@chromium.org, bbudge@chromium.org, bradnelson@chromium.org BUG=v8:6532 Change-Id: I710ee8ef566c5e33866afdf5b47375c2ea6fdbe6 Reviewed-on: https://chromium-review.googlesource.com/595241Reviewed-by: Bill Budge <bbudge@chromium.org> Reviewed-by: Brad Nelson <bradnelson@chromium.org> Reviewed-by: Ben Smith <binji@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#47102}
-
- 26 Jan, 2017 1 commit
-
-
bbudge authored
- Adds Int16x8, Int8x16 types. - Adds neg, abs unary ops. - Adds add, sub, mul, and signed / unsigned min / max, comparison ops. LOG=N BUG=v8:4124 Review-Url: https://codereview.chromium.org/2638133002 Cr-Commit-Position: refs/heads/master@{#42674}
-
- 22 Aug, 2016 1 commit
-
-
ahaas authored
The new operators are implemented similar to the Float64(Max|Min) which already exist. The purpose of the new operators is the implementation of the F32Max and F32Min instructions in WebAssembly. R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-mips-ports@googlegroups.com Review-Url: https://codereview.chromium.org/2252863003 Cr-Commit-Position: refs/heads/master@{#38784}
-
- 12 Jul, 2016 1 commit
-
-
ahaas authored
I removed or replaced some values in the list of float and double values in value-helper.h which cannot be represented precisely as floats or doubles, respectively. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2135243004 Cr-Commit-Position: refs/heads/master@{#37671}
-
- 30 Jun, 2016 1 commit
-
-
ahaas authored
In the current implementation of wasm an unrepresentable input of the float32-to-int32 conversion is detected by first truncating the input, then converting the truncated input to int32 and back to float32, and then checking whether the result is the same as the truncated input. This input check does not work on arm and arm64 for an input of (INT32_MAX + 1) because on these platforms the float32-to-int32 conversion results in INT32_MAX if the input is greater than INT32_MAX. When INT32_MAX is converted back to float32, then the result is (INT32_MAX + 1) again because INT32_MAX cannot be represented precisely as float32, and rounding-to-nearest results in (INT32_MAX + 1). Since (INT32_MAX + 1) equals the truncated input value, the input appears to be representable. With the changes in this CL, the result of the float32-to-int32 conversion is incremented by 1 if the original result was INT32_MAX. Thereby the detection of unrepresenable inputs in wasm works. Note that since INT32_MAX cannot be represented precisely in float32, it can also never be a valid result of the float32-to-int32 conversion. @v8-mips-ports, can you do a similar implementation for mips? R=titzer@chromium.org, Rodolph.Perfetta@arm.com Review-Url: https://codereview.chromium.org/2105313002 Cr-Commit-Position: refs/heads/master@{#37448}
-
- 13 Jun, 2016 2 commits
-
-
bmeurer authored
Import base::ieee754::atan() and base::ieee754::atan2() from fdlibm and introduce Float64Atan and Float64Atan2 TurboFan operators based on those, similar to what we already did for Float64Log and Float64Log1p. Rewrite Math.atan() and Math.atan2() as TurboFan builtin and use the operators to also inline Math.atan() and Math.atan2() into optimized TurboFan functions. R=yangguo@chromium.org BUG=v8:5086,v8:5095 Review-Url: https://codereview.chromium.org/2065503002 Cr-Commit-Position: refs/heads/master@{#36916}
-
bmeurer authored
Import base::ieee754::log1p() from fdlibm and introduce a Float64Log1p TurboFan operator based on that, similar to what we do for Float64Log. Rewrite Math.log1p() as TurboFan builtin and use that operator to also inline Math.log1p() into optimized TurboFan functions. Also unify the handling of the special IEEE 754 functions somewhat in the TurboFan backends. At some point we can hopefully express this completely in the InstructionSelector (once we have an idea what to do with the ST(0) return issue on IA-32/X87). Drive-by-fix: Add some more test coverage for the log function. R=yangguo@chromium.org BUG=v8:5086,v8:5092 Review-Url: https://codereview.chromium.org/2060743002 Cr-Commit-Position: refs/heads/master@{#36914}
-
- 10 Jun, 2016 1 commit
-
-
bmeurer authored
This switches Math.log to use an fdlibm based version of log, imported as base::ieee754::log, and use that consistently everywhere, i.e. change the Float64Log TurboFan operators on Intel to use the C++ implementation as well (same for Crankshaft). R=yangguo@chromium.org BUG=v8:5065,v8:5086 Review-Url: https://codereview.chromium.org/2053893003 Cr-Commit-Position: refs/heads/master@{#36880}
-
- 31 Mar, 2016 1 commit
-
-
ahaas authored
R=titzer@chromium.org Review URL: https://codereview.chromium.org/1843123002 Cr-Commit-Position: refs/heads/master@{#35173}
-
- 07 Mar, 2016 1 commit
-
-
ahaas authored
Instead of using CheckFloatEq and CheckDoubleEq directly, I introduced a macro which first stores the expected result in a volatile variable. Here are some comments of previous CLs: The reason is same as the CL #31808 (issue 1430943002, X87: Change the test case for X87 float operations), please refer: https://codereview.chromium.org/1430943002/. Here is the key comments from CL #31808 Some new test cases use CheckFloatEq(...) and CheckDoubleEq(...) function for result check. When GCC compiling the CheckFloatEq() and CheckDoubleEq() function, those inlined functions has different behavior comparing with GCC ia32 build and x87 build. The major difference is sse float register still has single precision rounding semantic. While X87 register has no such rounding precsion semantic when directly use register value. The V8 turbofan JITTed has exactly same result in both X87 and IA32 port. So we add the following sentence to do type cast to keep the same precision for RunCallInt64ToFloat32/RunCallInt64ToFloat64. Such as: volatile double expect = static_cast<float>(*i). R=titzer@chromium.org, weiliang.lin@intel.com Review URL: https://codereview.chromium.org/1773513002 Cr-Commit-Position: refs/heads/master@{#34534}
-
- 18 Feb, 2016 1 commit
-
-
ahaas authored
The BufferedRawMachineAssemblerTester caused problems for the Int64Lowering. Instead we construct a TF graph now which is compiled by Pipeline::GenerateCodeForTesting. R=titzer@chromium.org Review URL: https://codereview.chromium.org/1702023002 Cr-Commit-Position: refs/heads/master@{#34107}
-
- 18 Jan, 2016 2 commits
-
-
ahaas authored
Revert of [turbofan] Implement rounding of floats on x64 and ia32 without sse4.1. (patchset #2 id:20001 of https://codereview.chromium.org/1584663007/ ) Reason for revert: Code is incorrect for -0. Original issue's description: > [turbofan] Implement rounding of floats on x64 and ia32 without sse4.1. > > The implementation sets the rounding mode flag and then uses the > cvtsd2si and cvtsi2sd instructions (convert between float and int) to do > the rounding. Input values outside int range either don't have to be > rounded anyways, or are rounded by calculating input + 2^52 - 2^52 for > positive inputs, or input -2^52 + 2^52 for negative inputs. The original > rounding mode is restored afterwards. > > R=titzer@chromium.org > > B=575379 > > Committed: https://crrev.com/fa5d09e547abe79a8c82f780deb980c53ad78beb > Cr-Commit-Position: refs/heads/master@{#33367} TBR=titzer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1593313010 Cr-Commit-Position: refs/heads/master@{#33369}
-
ahaas authored
The implementation sets the rounding mode flag and then uses the cvtsd2si and cvtsi2sd instructions (convert between float and int) to do the rounding. Input values outside int range either don't have to be rounded anyways, or are rounded by calculating input + 2^52 - 2^52 for positive inputs, or input -2^52 + 2^52 for negative inputs. The original rounding mode is restored afterwards. R=titzer@chromium.org B=575379 Review URL: https://codereview.chromium.org/1584663007 Cr-Commit-Position: refs/heads/master@{#33367}
-
- 17 Dec, 2015 1 commit
-
-
ahaas authored
As required by the spec, the second return value now returns success also for the range between 0 and -1 where the conversion results in 0. R=bradnelson@chromium.org, mstarzinger@chromium.org, v8-arm-ports@googlegroups.com, v8-mips-ports@googlegroups.com Review URL: https://codereview.chromium.org/1533503002 Cr-Commit-Position: refs/heads/master@{#32936}
-
- 16 Dec, 2015 1 commit
-
-
ahaas authored
On x64 and arm64 TryTruncateFloatXXToInt64 incorrectly failed when the input was INT64_MIN. R=bradnelson@chromium.org, mstarzinger@chromium.org, v8-arm-ports@googlegroups.com Review URL: https://codereview.chromium.org/1526293002 Cr-Commit-Position: refs/heads/master@{#32908}
-
- 11 Dec, 2015 1 commit
-
-
ahaas authored
TryTruncateFloat32ToUint64 converts a float32 to a uint64. Additionally it provides an optional second return value which indicates whether the conversion succeeded (i.e. float32 value was within uint64 range) or not. I implemented the new operator on x64, arm64, and mips64. @v8-ppc-ports, can you please take care of the ppc64 implementation of the second output? Additionally I fixed a bug on x64 and mips64 in the implementation of TryTruncateFloat64ToUint64. Cases where the input value was between -1 and 0 were handled incorrectly. R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-mips-ports@googlegroups.com Review URL: https://codereview.chromium.org/1512023002 Cr-Commit-Position: refs/heads/master@{#32796}
-
- 09 Dec, 2015 1 commit
-
-
ahaas authored
This operator now provides a second output which indicates whether the conversion from float64 to uint64 was successful or not. The second output returns 0 if the conversion fails, or something else if the conversion succeeds. The second output can be ignored, which means that the operator can be used the same as the original operator. I implement the new operator on x64 and arm64. @v8-mips-ports and @v8-ppc-ports, can you please take care of the mips64 and ppc64 implementation of the second output? R=titzer@chromium.org, v8-arm-ports@googlegroups.com Review URL: https://codereview.chromium.org/1507703002 Cr-Commit-Position: refs/heads/master@{#32705}
-
- 12 Nov, 2015 1 commit
-
-
ahaas authored
The least significant bit of the input value may affect the result of the conversion through rounding. We OR the least significant with the second least significant bit to preserve it over the SHR instruction. R=titzer@chromium.org Review URL: https://codereview.chromium.org/1435203003 Cr-Commit-Position: refs/heads/master@{#31969}
-
- 28 Oct, 2015 1 commit
-
-
mstarzinger authored
R=jochen@chromium.org Review URL: https://codereview.chromium.org/1417163004 Cr-Commit-Position: refs/heads/master@{#31632}
-
- 23 Sep, 2015 1 commit
-
-
titzer authored
R=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1360133002 Cr-Commit-Position: refs/heads/master@{#30884}
-
- 31 Aug, 2015 1 commit
-
-
mstarzinger authored
The usage of Unique<T> throughout the TurboFan IR does not have any advantage. There is no single point in time when they are initialized and most use-sites looked through to the underlying Handle<T> anyways. Also there already was a mixture of Handle<T> versus Unique<T> in the graph and this unifies the situation to use Handle<T> everywhere. R=bmeurer@chromium.org,titzer@chromium.org Review URL: https://codereview.chromium.org/1314473007 Cr-Commit-Position: refs/heads/master@{#30458}
-
- 08 Apr, 2015 1 commit
-
-
Benedikt Meurer authored
These operators compute the absolute floating point value of some arbitrary input, and are implemented without any branches (i.e. using vabs on arm, and andps/andpd on x86). R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/1066393002 Cr-Commit-Position: refs/heads/master@{#27662}
-
- 30 Jan, 2015 2 commits
-
-
bmeurer authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/877753007 Cr-Commit-Position: refs/heads/master@{#26346}
-
Benedikt Meurer authored
This reverts commit 6a4c0a3b and commit 0deaa4b6 for breaking GCC bots. TBR=svenpanne@chromium.org Review URL: https://codereview.chromium.org/893533003 Cr-Commit-Position: refs/heads/master@{#26342}
-