- 08 Jun, 2017 1 commit
-
-
bbudge authored
- Eliminates b1x4, b1x8, and b1x16 as distinct WASM types. - All vector comparisons return v128 type. - Eliminates b1xN and, or, xor, not. - Selects take a v128 mask vector and are now bit-wise. - Adds a new test for Select, where mask is non-canonical (not 0's and -1's). LOG=N BUG=v8:6020 Review-Url: https://codereview.chromium.org/2919203002 Cr-Commit-Position: refs/heads/master@{#45795}
-
- 22 May, 2017 1 commit
-
-
Wiktor Garbacz authored
Change-Id: I20ed35a7fb5104a9cc66bb54fa8966589c43d7f9 Reviewed-on: https://chromium-review.googlesource.com/507287Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Daniel Clifford <danno@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Cr-Commit-Position: refs/heads/master@{#45458}
-
- 16 May, 2017 1 commit
-
-
ivica.bogosavljevic authored
Reland d8bfdb7a Original commit message: If alignment parameter is set, the memory returned by the StackSlot operator will be aligned according to the parameter. The implementation goes like this. If alignment parameter is set we allocate a bit more memory than actually needed and so we can move the beginning of the StackSlot in order to have it aligned. BUG= Review-Url: https://codereview.chromium.org/2874713003 Cr-Commit-Position: refs/heads/master@{#45339}
-
- 09 May, 2017 2 commits
-
-
machenbach authored
Revert of [turbofan] Add alignment parameter to StackSlot operator (patchset #7 id:120001 of https://codereview.chromium.org/2816743003/ ) Reason for revert: Seems to break cfi: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20cfi/builds/9989 Original issue's description: > [turbofan] Add alignment parameter to StackSlot operator > > If alignment parameter is set, the memory returned by the > StackSlot operator will be aligned according to the parameter. > > The implementation goes like this. If alignment parameter is set > we allocate a bit more memory than actually needed and so we > can move the beginning of the StackSlot in order to have it aligned. > > > BUG= > > Review-Url: https://codereview.chromium.org/2816743003 > Cr-Commit-Position: refs/heads/master@{#45197} > Committed: https://chromium.googlesource.com/v8/v8/+/d8bfdb7a998adadc56aa5705a5998e75ceae7675 TBR=ahaas@chromium.org,clemensh@chromium.org,titzer@chromium.org,bmeurer@chromium.org,ivica.bogosavljevic@imgtec.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review-Url: https://codereview.chromium.org/2867403002 Cr-Commit-Position: refs/heads/master@{#45203}
-
ivica.bogosavljevic authored
If alignment parameter is set, the memory returned by the StackSlot operator will be aligned according to the parameter. The implementation goes like this. If alignment parameter is set we allocate a bit more memory than actually needed and so we can move the beginning of the StackSlot in order to have it aligned. BUG= Review-Url: https://codereview.chromium.org/2816743003 Cr-Commit-Position: refs/heads/master@{#45197}
-
- 31 Mar, 2017 1 commit
-
-
jyan authored
some arch like s390 has native instr can benefit from this. see ~10% improvement on MathAbs on s390 Review-Url: https://codereview.chromium.org/2785773002 Cr-Commit-Position: refs/heads/master@{#44310}
-
- 21 Mar, 2017 1 commit
-
-
bbudge authored
- Adds a FinishCode method to CodeGenerator, and implements it for all platforms. ARM and ARM64 flush constants, all other platforms do nothing. - Remove old static free function. LOG=N BUG=none Review-Url: https://codereview.chromium.org/2748383004 Cr-Commit-Position: refs/heads/master@{#43990}
-
- 21 Feb, 2017 1 commit
-
-
bbudge authored
- Adds new machine types SimdBool4/8/16 for the different boolean vector types. - Adds a kSimdMaskRegisters flag for each platform. These are all false for now. - Removes Create, ExtractLane, ReplaceLane, Equal, NotEqual, Swizzle and Shuffle opcodes from the Boolean types. These are unlikely to be well supported natively, and can be synthesized using Select. - Changes the signature of Relational opcodes to return boolean vectors. - Changes the signature of Select opcodes to take boolean vectors. - Updates the ARM implementation of Relational and Select opcodes. LOG=N BUG=v8:4124 Review-Url: https://codereview.chromium.org/2700813002 Cr-Commit-Position: refs/heads/master@{#43348}
-
- 10 Feb, 2017 1 commit
-
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2682143002 Cr-Original-Commit-Position: refs/heads/master@{#43065} Committed: https://chromium.googlesource.com/v8/v8/+/193a0c118845d068ab386b5c90d04daaa64e1e86 Review-Url: https://codereview.chromium.org/2682143002 Cr-Commit-Position: refs/heads/master@{#43085}
-
- 09 Feb, 2017 2 commits
-
-
machenbach authored
Revert of [compiler] Pass deoptimization_kind through DeoptimizeParameters and FlagsContinuation (patchset #3 id:40001 of https://codereview.chromium.org/2682143002/ ) Reason for revert: cfi failure: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20cfi/builds/8635 Original issue's description: > [compiler] Pass deoptimization_kind through DeoptimizeParameters and FlagsContinuation > > BUG= > > Review-Url: https://codereview.chromium.org/2682143002 > Cr-Commit-Position: refs/heads/master@{#43065} > Committed: https://chromium.googlesource.com/v8/v8/+/193a0c118845d068ab386b5c90d04daaa64e1e86 TBR=jarin@chromium.org,verwaest@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review-Url: https://codereview.chromium.org/2683203002 Cr-Commit-Position: refs/heads/master@{#43070}
-
verwaest authored
BUG= Review-Url: https://codereview.chromium.org/2682143002 Cr-Commit-Position: refs/heads/master@{#43065}
-
- 08 Feb, 2017 2 commits
-
-
zhengxing.li authored
port 81700ddf(r42213) original commit message: and rename WasmFrame to WasmCompiledFrame. The WasmToInterpreterFrames are not used yet; this will follow in a follow-up CL (see tracking bug for the overall picture). Those frames will represent frames for WASM_TO_INTERPRETER stubs, which call from wasm code to the wasm interpreter, implemented in C++. They will support the Summarize method to inspect the stack frames in the wasm interpreter. BUG= Review-Url: https://codereview.chromium.org/2682713002 Cr-Commit-Position: refs/heads/master@{#43023}
-
zhengxing.li authored
port b29d6d49(r41790) original commit message: This also fixes UBSAN failures due to improper OpParameter<> calls. BUG= Review-Url: https://codereview.chromium.org/2681763002 Cr-Commit-Position: refs/heads/master@{#43022}
-
- 07 Feb, 2017 1 commit
-
-
zhengxing.li authored
port f435d622(r41735) original commit message: Original commit message: [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code. Some instructions in WebAssembly trap for some inputs, which means that the execution is terminated and (at least at the moment) a JavaScript exception is thrown. Examples for traps are out-of-bounds memory accesses, or integer divisions by zero. Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5 TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position constant), in addition to the trap condition itself. Additionally, each WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose number of inputs is linear to the number of trap checks in the function. Especially for functions with high numbers of trap checks we observe a significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing a TrapIf common operator only a single node is necessary per trap check, in addition to the trap condition. Also the nodes which are shared between trap checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a speedup of 30-50% on average. This CL only implements TrapIf and TrapUnless on x64. The implementation is also hidden behind the --wasm-trap-if flag. Please take a special look at how the source position is transfered from the instruction selector to the code generator, and at the context that is used for the runtime call. BUG= Review-Url: https://codereview.chromium.org/2679853002 Cr-Commit-Position: refs/heads/master@{#42998}
-
- 23 Jan, 2017 3 commits
-
-
zhengxing.li authored
port ea925431 (r42545) original commit message: On ia32 return statements in C++ automatically convert signalling NaNs to quiet NaNs, even when bit_cast is used. This CL removes all uses of bit_cast<float> and bit_cast<double> in the wasm compiler and wasm interpreter. BUG= Review-Url: https://codereview.chromium.org/2648203002 Cr-Commit-Position: refs/heads/master@{#42588}
-
zhengxing.li authored
port 037200e6 (r42486) original commit message: The IA32AddPair and IA32SubPair instructions were using an input register as a temporary value, which led to registers sometimes being clobbered when they shouldn't have been. This led to problems, for example, in calling printf to format doubles: printf("%f", 1.2345) => 0.61725 (on x86) BUG= Review-Url: https://codereview.chromium.org/2645233002 Cr-Commit-Position: refs/heads/master@{#42587}
-
zhengxing.li authored
port 95a9b761 (r42344) original commit message: Recognize and emit in-memory comparisons of 8-bit and 16-bit values with immediate values that fit. BUG= Review-Url: https://codereview.chromium.org/2651553002 Cr-Commit-Position: refs/heads/master@{#42585}
-
- 11 Jan, 2017 1 commit
-
-
zhengxing.li authored
port 0c4b8ff4 (r42192) original commit message: - Refactor Dispatch tables to have separate function, signature tables - New Relocation type for WasmFunctionTableReference, assembler, compiler support. - RelocInfo helper functions for Wasm references BUG= Review-Url: https://codereview.chromium.org/2623133002 Cr-Commit-Position: refs/heads/master@{#42208}
-
- 09 Jan, 2017 1 commit
-
-
zhengxing.li authored
X87: Revert of [turbofan] Improve codegen for 8- and 16-bit memory comparisons on Intel platforms (patchset #3 id:40001 of https://codereview.chromium.org/2605863002/ ). port c16ca32e (r42092) original commit message: Reason for revert: Breaks wasm benchmark (http://crbug.com/v8/5798). Original issue's description: > [turbofan] Improve codegen for 8- and 16-bit memory comparisons on Intel platforms > > Recognize and emit in-memory comparisons of 8-bit and 16-bit values with > immediate values that fit. > > LOG=N > R=epertoso@chromium.org > > Review-Url: https://codereview.chromium.org/2605863002 > Cr-Commit-Position: refs/heads/master@{#41971} > Committed: https://chromium.googlesource.com/v8/v8/+/be11812c53ff6c8ce320887bc76a3b60d8103695 BUG= Review-Url: https://codereview.chromium.org/2622463002 Cr-Commit-Position: refs/heads/master@{#42126}
-
- 03 Jan, 2017 1 commit
-
-
zhengxing.li authored
port be11812c (r41971) original commit message: Recognize and emit in-memory comparisons of 8-bit and 16-bit values with immediate values that fit. BUG= Review-Url: https://codereview.chromium.org/2612503002 Cr-Commit-Position: refs/heads/master@{#42017}
-
- 19 Dec, 2016 1 commit
-
-
titzer authored
This also fixes UBSAN failures due to improper OpParameter<> calls. R=machenbach@chromium.org, clemensh@chromium.org BUG= Review-Url: https://codereview.chromium.org/2587763003 Cr-Commit-Position: refs/heads/master@{#41790}
-
- 15 Dec, 2016 1 commit
-
-
ahaas authored
Some instructions in WebAssembly trap for some inputs, which means that the execution is terminated and (at least at the moment) a JavaScript exception is thrown. Examples for traps are out-of-bounds memory accesses, or integer divisions by zero. Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5 TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position constant), in addition to the trap condition itself. Additionally, each WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose number of inputs is linear to the number of trap checks in the function. Especially for functions with high numbers of trap checks we observe a significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing a TrapIf common operator only a single node is necessary per trap check, in addition to the trap condition. Also the nodes which are shared between trap checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a speedup of 30-50% on average. This CL only implements TrapIf and TrapUnless on x64. The implementation is also hidden behind the --wasm-trap-if flag. Please take a special look at how the source position is transfered from the instruction selector to the code generator, and at the context that is used for the runtime call. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2562393002 Cr-Commit-Position: refs/heads/master@{#41720}
-
- 30 Nov, 2016 1 commit
-
-
eholk authored
This is necessary for signal-based out of bounds handling in WebAssembly. Adds a ProtectedStore instruction that is analogous to the previously added ProtectedLoad instruction. Rather than using bounds checks, ProtectedStore emits an out of line section of code that throws a JavaScript exception and provides the necessary metadata for a signal handler to be able to find the out of line code. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2516413003 Cr-Commit-Position: refs/heads/master@{#41398}
-
- 14 Nov, 2016 1 commit
-
-
tebbi authored
This CL enables precise source positions for all V8 compilers. It merges compiler::SourcePosition and internal::SourcePosition to a single class used throughout the codebase. The new internal::SourcePosition instances store an id identifying an inlined function in addition to a script offset. SourcePosition::InliningId() refers to a the new table DeoptimizationInputData::InliningPositions(), which provides the following data for every inlining id: - The inlined SharedFunctionInfo as an offset into DeoptimizationInfo::LiteralArray - The SourcePosition of the inlining. Recursively, this yields the full inlining stack. Before the Code object is created, the same information can be found in CompilationInfo::inlined_functions(). If SourcePosition::InliningId() is SourcePosition::kNotInlined, it refers to the outer (non-inlined) function. So every SourcePosition has full information about its inlining stack, as long as the corresponding Code object is known. The internal represenation of a source position is a positive 64bit integer. All compilers create now appropriate source positions for inlined functions. In the case of Turbofan, this required using AstGraphBuilderWithPositions for inlined functions too. So this class is now moved to a header file. At the moment, the additional information in source positions is only used in --trace-deopt and --code-comments. The profiler needs to be updated, at the moment it gets the correct script offsets from the deopt info, but the wrong script id from the reconstructed deopt stack, which can lead to wrong outputs. This should be resolved by making the profiler use the new inlining information for deopts. I activated the inlined deoptimization tests in test-cpu-profiler.cc for Turbofan, changing them to a case where the deopt stack and the inlining position agree. It is currently still broken for other cases. The following additional changes were necessary: - The source position table (internal::SourcePositionTableBuilder etc.) supports now 64bit source positions. Encoding source positions in a single 64bit int together with the difference encoding in the source position table results in very little overhead for the inlining id, since only 12% of the source positions in Octane have a changed inlining id. - The class HPositionInfo was effectively dead code and is now removed. - SourcePosition has new printing and information facilities, including computing a full inlining stack. - I had to rename compiler/source-position.{h,cc} to compiler/compiler-source-position-table.{h,cc} to avoid clashes with the new src/source-position.cc file. - I wrote the new wrapper PodArray for ByteArray. It is a template working with any POD-type. This is used in DeoptimizationInputData::InliningPositions(). - I removed HInlinedFunctionInfo and HGraph::inlined_function_infos, because they were only used for the now obsolete Crankshaft inlining ids. - Crankshaft managed a list of inlined functions in Lithium: LChunk::inlined_functions. This is an analog structure to CompilationInfo::inlined_functions. So I removed LChunk::inlined_functions and made Crankshaft use CompilationInfo::inlined_functions instead, because this was necessary to register the offsets into the literal array in a uniform way. This is a safe change because LChunk::inlined_functions has no other uses and the functions in CompilationInfo::inlined_functions have a strictly longer lifespan, being created earlier (in Hydrogen already). BUG=v8:5432 Review-Url: https://codereview.chromium.org/2451853002 Cr-Commit-Position: refs/heads/master@{#40975}
-
- 11 Nov, 2016 1 commit
-
-
ulan authored
BUG=v8:5614 Review-Url: https://codereview.chromium.org/2493173002 Cr-Commit-Position: refs/heads/master@{#40916}
-
- 08 Nov, 2016 2 commits
-
-
zhengxing.li authored
port 9b308dca (r40721) original commit message: BUG= Review-Url: https://codereview.chromium.org/2485033002 Cr-Commit-Position: refs/heads/master@{#40818}
-
zhengxing.li authored
port 4447405b (r40712) original commit message: BUG= Review-Url: https://codereview.chromium.org/2486433004 Cr-Commit-Position: refs/heads/master@{#40816}
-
- 01 Nov, 2016 1 commit
-
-
zhengxing.li authored
port 5319b50c (r40678) original commit message: This is preparation for using TF to create builtins that handle variable number of arguments and have to remove these arguments dynamically from the stack upon return. The gist of the changes: - Added a second argument to the Return node which specifies the number of stack slots to pop upon return in addition to those specified by the Linkage of the compiled function. - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should handles all tail-call cases except where the return value type differs, this fallback was not really useful and in fact caused unexpected behavior with variable sized argument popping, since it wasn't possible to materialize a Return node with the right pop count from the TailCall without additional context. - Modified existing Return generation to pass a constant zero as the additional pop argument since the variable pop functionality BUG= Review-Url: https://codereview.chromium.org/2469623002 Cr-Commit-Position: refs/heads/master@{#40684}
-
- 26 Oct, 2016 1 commit
-
-
mstarzinger authored
The tail-call operator for invoking a JSFunction object from within stub code has been dead for a while and untested by now. This removes support for such a construct. R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2452943002 Cr-Commit-Position: refs/heads/master@{#40583}
-
- 20 Oct, 2016 1 commit
-
-
zhengxing.li authored
port 99023682 (r40446) original commit message: The scheduler expects a trimmed graph, so we have to trim the graph before scheduling. BUG= Review-Url: https://chromiumcodereview.appspot.com/2431213003 Cr-Commit-Position: refs/heads/master@{#40454}
-
- 18 Oct, 2016 1 commit
-
-
zhengxing.li authored
port 87ae05c7 (r40341) original commit message: Utilize all opportunities to turn leas into adds. BUG= Review-Url: https://codereview.chromium.org/2429763002 Cr-Commit-Position: refs/heads/master@{#40386}
-
- 26 Sep, 2016 1 commit
-
-
tebbi authored
R=bmeurer@chromium.org,jarin@chromium.org BUG= Review-Url: https://codereview.chromium.org/2366993002 Cr-Commit-Position: refs/heads/master@{#39733}
-
- 21 Sep, 2016 1 commit
-
-
mstarzinger authored
This removes an optimization from the code generator that tries to materialize certain constants (i.e. context and closure) from the stackframe when possible. This does not work with Harmony tail calls which are split into several instructions. There have already been numerous bugs in this optimization, it is too fragile in its current form. R=bmeurer@chromium.org TEST=mjsunit/regress/regress-crbug-648539 BUG=chromium:648539 Review-Url: https://codereview.chromium.org/2357583003 Cr-Commit-Position: refs/heads/master@{#39583}
-
- 09 Sep, 2016 1 commit
-
-
eholk authored
This CL introduces a ProtectedLoad instruction with is needed for out of bounds trap handling. ProtectedLoad behaves like a regular load, but it takes a context and source position parameter as well. These are used by an out of line code fragment to generate code to throw a JS exception for an out of bounds memory reference in Wasm. These changes a cleaned up subset of https://codereview.chromium.org/2148743004/ The rest of this feature will follow in future CLs. This includes a table mapping memory instructions to landing pads as well as the actual signal handler. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2301833004 Cr-Commit-Position: refs/heads/master@{#39318}
-
- 31 Aug, 2016 1 commit
-
-
marja authored
This way, many files which only need CompilationInfo but not compiler.h and its dependencies can include just compilation-info.h. BUG= Review-Url: https://codereview.chromium.org/2284313003 Cr-Commit-Position: refs/heads/master@{#39038}
-
- 30 Aug, 2016 1 commit
-
-
zhengxing.li authored
port 56429fc1 (r38978) original commit message: Introduced MachineType::TaggedSigned() and TaggedPointer(). The idea is to quit using the representational dimension of Type, and instead encode this information in the MachineRepresentation (itself lightly wrapped in MachineType, along with MachineSemantic). There are three parts to the whole change: 1) Places that set the machine representation - constant nodes, loads nad stores, global object and native context specialization. 2) Places that propagate type/representation - this is representation inference (aka simplified lowering). At the end of this process we expect to have a MachineRepresentation for every node. An interesting part of this is phi merging. 3) Places that examine representation - WriteBarrier elimination does this. Currently it's looking at the Type representation dimension, but as a part of this change (or in a soon-to-follow change) it can simply examine the MachineRepresentation. BUG= Review-Url: https://codereview.chromium.org/2293603003 Cr-Commit-Position: refs/heads/master@{#38993}
-
- 25 Aug, 2016 3 commits
-
-
jarin authored
This reverts commit a55fdb1e, relands https://codereview.chromium.org/2266823002/. BUG=chromium:638132 Review-Url: https://codereview.chromium.org/2277283002 Cr-Commit-Position: refs/heads/master@{#38917}
-
bmeurer authored
Revert of [turbofan] Insert dummy values when changing from None type. (patchset #5 id:80001 of https://codereview.chromium.org/2266823002/ ) Reason for revert: Octane/Mandreel aborts with an exception now: TypeError: __FUNCTION_TABLE__[(r2 >> 2)] is not a function Original issue's description: > [turbofan] Insert dummy values when changing from None type. > > Currently we choose the MachineRepresentation::kNone representation for > values of Type::None, and when converting values from the kNone representation > we use "impossible" conversions that will crash at runtime. This > assumes that the impossible conversions should never be hit (the only > way to produce the impossible values is to perform an always-failing > runtime check on a value, such as Smi-checking a string). Note that > this assumes that the runtime check is executed before the impossible > convesrion. > > Introducing BitwiseOr type feedback broke this in two ways: > > - we always pick Word32 representation for bitwise-or, so the > impossible conversion does not trigger (it only triggers with > None representation), and we could end up with unsupported > conversions from Word32. > > - even if we inserted impossible conversions, they are pure conversions. > Since untagging, bitwise-or operations are also pure, we could hoist > all these before the smi check of the inputs and we could hit the > impossible conversions before we get to the smi check. > > This CL addresses this by just providing dummy values for conversions > from the Type::None type. It also removes the impossible-to-* conversions. > > BUG=chromium:638132 > > Committed: https://crrev.com/c83b21ab755f1420b6da85b3ff43d7e96ead9bbe > Cr-Commit-Position: refs/heads/master@{#38883} TBR=mstarzinger@chromium.org,jarin@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:638132 Review-Url: https://codereview.chromium.org/2280613002 Cr-Commit-Position: refs/heads/master@{#38893}
-
jarin authored
Currently we choose the MachineRepresentation::kNone representation for values of Type::None, and when converting values from the kNone representation we use "impossible" conversions that will crash at runtime. This assumes that the impossible conversions should never be hit (the only way to produce the impossible values is to perform an always-failing runtime check on a value, such as Smi-checking a string). Note that this assumes that the runtime check is executed before the impossible convesrion. Introducing BitwiseOr type feedback broke this in two ways: - we always pick Word32 representation for bitwise-or, so the impossible conversion does not trigger (it only triggers with None representation), and we could end up with unsupported conversions from Word32. - even if we inserted impossible conversions, they are pure conversions. Since untagging, bitwise-or operations are also pure, we could hoist all these before the smi check of the inputs and we could hit the impossible conversions before we get to the smi check. This CL addresses this by just providing dummy values for conversions from the Type::None type. It also removes the impossible-to-* conversions. BUG=chromium:638132 Review-Url: https://codereview.chromium.org/2266823002 Cr-Commit-Position: refs/heads/master@{#38883}
-
- 24 Aug, 2016 1 commit
-
-
zhengxing.li authored
port 2027b0be (r38784) original commit message: 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. BUG= Review-Url: https://codereview.chromium.org/2270193003 Cr-Commit-Position: refs/heads/master@{#38857}
-