- 13 Dec, 2017 1 commit
-
-
Sigurd Schneider authored
Bug: v8:7127 Change-Id: Iec65ead1540289aa99f496fd66595f2de88db68c Reviewed-on: https://chromium-review.googlesource.com/817417Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#50062}
-
- 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}
-
- 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}
-
- 25 Jan, 2017 1 commit
-
-
jyan authored
BUG= Review-Url: https://codereview.chromium.org/2650813003 Cr-Commit-Position: refs/heads/master@{#42661}
-
- 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}
-
- 03 Nov, 2016 1 commit
-
-
jarin authored
Review-Url: https://codereview.chromium.org/2475433005 Cr-Commit-Position: refs/heads/master@{#40721}
-
- 24 Aug, 2016 1 commit
-
-
rodolph.perfetta authored
Mark deopt's input alive till the end of the deopt instruction so they cannot be reused as output. BUG=v8:5158 Review-Url: https://codereview.chromium.org/2247303007 Cr-Commit-Position: refs/heads/master@{#38875}
-
- 02 Aug, 2016 1 commit
-
-
bmeurer authored
When we narrow a signed32 comparison to uint8 or uint16 representation, we also need to change the condition to unsigned comparisons otherwise the comparison will be done on int16/int8 which interprets the narrowed bits wrong. R=epertoso@chromium.org BUG=v8:5254 Review-Url: https://codereview.chromium.org/2202803003 Cr-Commit-Position: refs/heads/master@{#38231}
-
- 25 Jul, 2016 1 commit
-
-
jarin authored
BUG=chromium:630611 Review-Url: https://codereview.chromium.org/2177483002 Cr-Commit-Position: refs/heads/master@{#37994}
-
- 18 Jul, 2016 1 commit
-
-
bmeurer authored
So far TurboFan wasn't adding the deoptimization reasons for eager/soft deoptimization exits that can be used by either the DevTools profiler or the --trace-deopt flag. This adds basic support for deopt reasons on Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through the reasons to the code generation. Also moves the DeoptReason to it's own file (to resolve include cycles) and drops unused reasons. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2161543002 Cr-Commit-Position: refs/heads/master@{#37823}
-
- 14 Jul, 2016 1 commit
-
-
mvstanton authored
BUG= Review-Url: https://codereview.chromium.org/2101123005 Cr-Commit-Position: refs/heads/master@{#37748}
-
- 13 Jul, 2016 1 commit
-
-
danno authored
Previously, the following schedule fragment: 1: Parameter[0](0) 2: Parameter[1](0) 7: Int32Constant[1] 8: Int32Sub(2, 7) 9: Load[kRepTagged|kTypeAny](1, 8) would generate the following code (on ia32): mov eax,[ebp+0x8] mov ecx,[ebp+0xc] sub eax,0x1 mov eax,[eax+ecx*1] Now it generates: mov eax,[ebp+0x8] mov ecx,[ebp+0xc] mov eax,[eax+ecx*1-1] Similar pattern matching also now works on x64. BUG=v8:5192 LOG=N Review-Url: https://codereview.chromium.org/2137323003 Cr-Commit-Position: refs/heads/master@{#37701}
-
- 11 Jul, 2016 1 commit
-
-
danno authored
By adding MachineType to LinkageLocation, it is possible not only to reason about the location of a LinkageLocation on the stack, but also about it's size. This will be useful in follow-on CLs that attempt to merge some of the parameter passing logic of tail calls and normal (non-tail) calls. As a nice side-effect, it is no longer necessary to separately keep a MachineSignature in a CallDescriptor, because the MachineTypes contianed in LinkageLocation for all of the Descriptor's parameters and return types are sufficient. This CL therefore removes the MachineSignature from the CallDescriptor and adjusts all the calling code accordingly, simplifying and de-duplicating code in a bunch of places. R=titzer@chromium.org, bmeurer@chromium.org LOG=N Review-Url: https://codereview.chromium.org/2124023003 Cr-Commit-Position: refs/heads/master@{#37633}
-
- 29 Jun, 2016 1 commit
-
-
georgia.kouveli authored
Perform the following transformation: | Before | After | |------------------+---------------------| | add w2, w0, w1 | adds w2, w0, w1 | | cmp w2, #0x0 | b.<cond'> <addr> | | b.<cond> <addr> | | |------------------+---------------------| | add w2, w0, w1 | adds w2, w0, w1 | | cmp #0x0, w2 | b.<cond'> <addr> | | b.<cond> <addr> | | and the same for and instructions instead of add. When the result of the add/and is not used, generate cmn/tst instead. We need to take care with which conditions we can handle and what new condition we map them to. BUG= Review-Url: https://codereview.chromium.org/2065243005 Cr-Commit-Position: refs/heads/master@{#37400}
-
- 09 Jun, 2016 1 commit
-
-
danno authored
Review-Url: https://codereview.chromium.org/2056503003 Cr-Commit-Position: refs/heads/master@{#36842}
-
- 27 May, 2016 1 commit
-
-
bbudge authored
- Renames UnallocatedOperandenum values to reflect the fact that there are multiple FP machine representations. - Renames enum values for RegisterAllocatorVerifier enum. - Template-izes DefineAsFixed and UseFixed methods to handle multiple FP register types. BUG=v8:4124 Review-Url: https://codereview.chromium.org/2017733002 Cr-Commit-Position: refs/heads/master@{#36558}
-
- 12 Apr, 2016 2 commits
-
-
gdeepti authored
Add relocatable pointers for wasm memory references that need to be updated when wasm GrowMemory is used. Code generator changes to accept relocatable constants as immediates. R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org Committed: https://crrev.com/eb5fe0df64ec0add423b2a1f6fb62d5a33dce2a5 Cr-Commit-Position: refs/heads/master@{#35182} Committed: https://crrev.com/297932a302ce0b73c3618ef9e4eba9d9d241f2b3 Cr-Commit-Position: refs/heads/master@{#35400} Review URL: https://codereview.chromium.org/1759383003 Cr-Commit-Position: refs/heads/master@{#35407}
-
machenbach authored
Revert of [compiler] Add relocatable pointer constants for wasm memory references. (patchset #15 id:320001 of https://codereview.chromium.org/1759383003/ ) Reason for revert: [Sheriff] Breaks msan: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/7842 Original issue's description: > [compiler] Add relocatable pointer constants for wasm memory references. > > Add relocatable pointers for wasm memory references that need to be updated when wasm GrowMemory is used. Code generator changes to accept relocatable constants as immediates. > > R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org > > Committed: https://crrev.com/eb5fe0df64ec0add423b2a1f6fb62d5a33dce2a5 > Cr-Commit-Position: refs/heads/master@{#35182} > > Committed: https://crrev.com/297932a302ce0b73c3618ef9e4eba9d9d241f2b3 > Cr-Commit-Position: refs/heads/master@{#35400} TBR=bradnelson@chromium.org,titzer@chromium.org,bmeurer@chromium.org,bradnelson@google.com,gdeepti@google.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1881913002 Cr-Commit-Position: refs/heads/master@{#35401}
-
- 11 Apr, 2016 1 commit
-
-
gdeepti authored
Add relocatable pointers for wasm memory references that need to be updated when wasm GrowMemory is used. Code generator changes to accept relocatable constants as immediates. R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org Committed: https://crrev.com/eb5fe0df64ec0add423b2a1f6fb62d5a33dce2a5 Cr-Commit-Position: refs/heads/master@{#35182} Review URL: https://codereview.chromium.org/1759383003 Cr-Commit-Position: refs/heads/master@{#35400}
-
- 01 Apr, 2016 2 commits
-
-
yangguo authored
Revert of [compiler] Add relocatable pointer constants for wasm memory references. (patchset #14 id:300001 of https://codereview.chromium.org/1759383003/ ) Reason for revert: Test failures: https://build.chromium.org/p/client.v8/builders/V8%20Mac64/builds/8046 Original issue's description: > [compiler] Add relocatable pointer constants for wasm memory references. > > Add relocatable pointers for wasm memory references that need to be updated when wasm GrowMemory is used. Code generator changes to accept relocatable constants as immediates. > > R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org > > Committed: https://crrev.com/eb5fe0df64ec0add423b2a1f6fb62d5a33dce2a5 > Cr-Commit-Position: refs/heads/master@{#35182} TBR=bradnelson@chromium.org,titzer@chromium.org,gdeepti@google.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1846083005 Cr-Commit-Position: refs/heads/master@{#35185}
-
gdeepti authored
Add relocatable pointers for wasm memory references that need to be updated when wasm GrowMemory is used. Code generator changes to accept relocatable constants as immediates. R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org Review URL: https://codereview.chromium.org/1759383003 Cr-Commit-Position: refs/heads/master@{#35182}
-
- 24 Feb, 2016 1 commit
-
-
bmeurer authored
These macro operators represent a conditional eager deoptimization exit without explicit branching, which greatly reduces overhead of both scheduling and register allocation, and thereby greatly reduces overall compilation time, esp. when there are a lot of eager deoptimization exits. R=jarin@chromium.org Review URL: https://codereview.chromium.org/1721103003 Cr-Commit-Position: refs/heads/master@{#34239}
-
- 10 Dec, 2015 1 commit
-
-
jarin authored
MachineType is now a class with two enum fields: - MachineRepresentation - MachineSemantic Both enums are usable on their own, and this change switches some places from using MachineType to use just MachineRepresentation. Most notably: - register allocator now uses just the representation. - Phi and Select nodes only refer to representations. Review URL: https://codereview.chromium.org/1513543003 Cr-Commit-Position: refs/heads/master@{#32738}
-
- 20 Nov, 2015 1 commit
-
-
danno authored
* Adds a PrepareForTailCall instruction that bumps the stack in the case that the number of parameters passed to the callee causes the stack to exceed the calleer's frame size. * Uses the gap resolver to move the saved caller return address and frame pointer to the approprate location in the tail-called frame. BUG=v8:4076 LOG=n Review URL: https://codereview.chromium.org/1455833004 Cr-Commit-Position: refs/heads/master@{#32151}
-
- 13 Nov, 2015 1 commit
-
-
mtrofin authored
We push the context and the js function onto the stack as part of the frame construction. The register allocator is presented with virtual registers for the above as defined from their corresponding registers. It then goes on to spilling them somewhere else on the stack. This means each function spends two redundant spills and two unnecessary stack slots. This change addresses this issue. We present these parameters (context and function) to the register allocator as an UnallocatedOperand having a "secondary storage". The secondary storage is then associated to the live range as its spill operand. We capture the definition of the live range so that we can then commit the spill (in this case, eliminate) through a variation of the mechanics of the CommitAssignment phase. The register allocator validator also needed update to understand UnallocatedOperands with a secondary storage. The change renames the SpillAtDefinitionList and related APIs to better capture their intent - the old names suggested spills happened upon calling. In reality, potential spill locations were thus recorded, and later committed (or not, in certain cases) after register allocation. BUG= v8:4548 LOG=n Review URL: https://codereview.chromium.org/1426943010 Cr-Commit-Position: refs/heads/master@{#31988}
-
- 04 Nov, 2015 1 commit
-
-
jarin authored
Review URL: https://codereview.chromium.org/1425183003 Cr-Commit-Position: refs/heads/master@{#31796}
-
- 27 Oct, 2015 1 commit
-
-
danno authored
Up until now, if one wanted to specify an explicit stack location or register as an operand for an instruction, it had to also be explicitly associated with a virtual register as a so-called FixedRegister or FixedStackSlot. For the implementation of tail calls, the plan is to use the gap resolver needs to shuffle stack locations from the caller to the tail-called callee. In order to do this, it must be possible to explicitly address operand locations on the stack that are not associated with virtual registers. This CL introduces ExplictOperands, which can specify a specific register or stack location that is not associated with virtual register. This will allow tail calls to specify the target locations for the necessary stack moves in the gap for the tail call without the core register allocation having to know about the target of the stack moves at all. In the process this CL: * creates a new Operand kind, ExplicitOperand, with which instructions can specify register and stack slots without an associated virtual register. * creates a LocationOperand class from which AllocatedOperand and ExplicitOperand are derived and provides a common interface to get Register, DoubleRegister and spill slot information. * removes RegisterOperand, DoubleRegisterOperand, StackSlotOperand and DoubleStackSlotOperand, they are subsumed by LocationOperand. * addresses a cleanup TODO in AllocatedOperand to reduce the redundancy of AllocatedOperand::Kind by using machine_type() to determine if an operand corresponds to a general purpose or double register. BUG=v8:4076 LOG=n Review URL: https://codereview.chromium.org/1389373002 Cr-Commit-Position: refs/heads/master@{#31603}
-
- 15 Oct, 2015 1 commit
-
-
jarin authored
Review URL: https://codereview.chromium.org/1398943003 Cr-Commit-Position: refs/heads/master@{#31283}
-
- 02 Oct, 2015 3 commits
-
-
danno authored
Previous to this patch, both the lithium and TurboFan register allocators tracked allocated registers by "indices", rather than the register codes used elsewhere in the runtime. This patch ensures that codes are used everywhere, and in the process cleans up a bunch of redundant code and adds more structure to how the set of allocatable registers is defined. Some highlights of changes: * TurboFan's RegisterConfiguration class moved to V8's top level so that it can be shared with Crankshaft. * Various "ToAllocationIndex" and related methods removed. * Code that can be easily shared between Register classes on different platforms is now shared. * The list of allocatable registers on each platform is declared as a list rather than implicitly via the register index <-> code mapping. Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2 Cr-Commit-Position: refs/heads/master@{#30913} Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf Cr-Commit-Position: refs/heads/master@{#31075} Review URL: https://codereview.chromium.org/1287383003 Cr-Commit-Position: refs/heads/master@{#31087}
-
danno authored
Revert of Reland: Remove register index/code indirection (patchset #20 id:380001 of https://codereview.chromium.org/1287383003/ ) Reason for revert: Failures on MIPS Original issue's description: > Remove register index/code indirection > > Previous to this patch, both the lithium and TurboFan register > allocators tracked allocated registers by "indices", rather than > the register codes used elsewhere in the runtime. This patch > ensures that codes are used everywhere, and in the process cleans > up a bunch of redundant code and adds more structure to how the > set of allocatable registers is defined. > > Some highlights of changes: > > * TurboFan's RegisterConfiguration class moved to V8's top level > so that it can be shared with Crankshaft. > * Various "ToAllocationIndex" and related methods removed. > * Code that can be easily shared between Register classes on > different platforms is now shared. > * The list of allocatable registers on each platform is declared > as a list rather than implicitly via the register index <-> > code mapping. > > Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2 > Cr-Commit-Position: refs/heads/master@{#30913} > > Committed: https://crrev.com/7b7a8205d9a00c678fb7a6e032a55fecbc1509cf > Cr-Commit-Position: refs/heads/master@{#31075} TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1380863004 Cr-Commit-Position: refs/heads/master@{#31083}
-
danno authored
Previous to this patch, both the lithium and TurboFan register allocators tracked allocated registers by "indices", rather than the register codes used elsewhere in the runtime. This patch ensures that codes are used everywhere, and in the process cleans up a bunch of redundant code and adds more structure to how the set of allocatable registers is defined. Some highlights of changes: * TurboFan's RegisterConfiguration class moved to V8's top level so that it can be shared with Crankshaft. * Various "ToAllocationIndex" and related methods removed. * Code that can be easily shared between Register classes on different platforms is now shared. * The list of allocatable registers on each platform is declared as a list rather than implicitly via the register index <-> code mapping. Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2 Cr-Commit-Position: refs/heads/master@{#30913} Review URL: https://codereview.chromium.org/1287383003 Cr-Commit-Position: refs/heads/master@{#31075}
-
- 24 Sep, 2015 2 commits
-
-
danno authored
Revert of Remove register index/code indirection (patchset #17 id:320001 of https://codereview.chromium.org/1287383003/ ) Reason for revert: Failures on greedy RegAlloc, Fuzzer Original issue's description: > Remove register index/code indirection > > Previous to this patch, both the lithium and TurboFan register > allocators tracked allocated registers by "indices", rather than > the register codes used elsewhere in the runtime. This patch > ensures that codes are used everywhere, and in the process cleans > up a bunch of redundant code and adds more structure to how the > set of allocatable registers is defined. > > Some highlights of changes: > > * TurboFan's RegisterConfiguration class moved to V8's top level > so that it can be shared with Crankshaft. > * Various "ToAllocationIndex" and related methods removed. > * Code that can be easily shared between Register classes on > different platforms is now shared. > * The list of allocatable registers on each platform is declared > as a list rather than implicitly via the register index <-> > code mapping. > > Committed: https://crrev.com/80bc6f6e11f79524e3f1ad05579583adfd5f18b2 > Cr-Commit-Position: refs/heads/master@{#30913} TBR=akos.palfi@imgtec.com,bmeurer@chromium.org,jarin@chromium.org,paul.lind@imgtec.com,titzer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1365073002 Cr-Commit-Position: refs/heads/master@{#30914}
-
danno authored
Previous to this patch, both the lithium and TurboFan register allocators tracked allocated registers by "indices", rather than the register codes used elsewhere in the runtime. This patch ensures that codes are used everywhere, and in the process cleans up a bunch of redundant code and adds more structure to how the set of allocatable registers is defined. Some highlights of changes: * TurboFan's RegisterConfiguration class moved to V8's top level so that it can be shared with Crankshaft. * Various "ToAllocationIndex" and related methods removed. * Code that can be easily shared between Register classes on different platforms is now shared. * The list of allocatable registers on each platform is declared as a list rather than implicitly via the register index <-> code mapping. Review URL: https://codereview.chromium.org/1287383003 Cr-Commit-Position: refs/heads/master@{#30913}
-
- 23 Sep, 2015 1 commit
-
-
pierre.langlois authored
This patch checks the type of the lhs operand of a floating point comparison, and commutes the operands if it is #0.0. It allows us to optimize a comparison with zero, as the fcmp instruction accepts #0.0 as rhs operand. Code before for "0.0 < 0.123": ------------------------------ fmov d1, xzr ldr d0, pc+96 fcmp d1, d0 b.lo #+0xc Code after: ----------- ldr d0, pc+92 fcmp d0, #0.0 b.gt #+0xc Before this patch, we used unsigned condition codes for floating point comparisons, but the unordered case was not correctly commuted. Review URL: https://codereview.chromium.org/1356283003 Cr-Commit-Position: refs/heads/master@{#30881}
-
- 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}
-
- 31 Jul, 2015 1 commit
-
-
titzer authored
R=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1268433003 Cr-Commit-Position: refs/heads/master@{#29955}
-
- 30 Jul, 2015 1 commit
-
-
danno authored
Add factory methods for different types of LinkageLocations, and ensure that accesses to the underlying data in the location are classified by type and funneled through explicit accessors. Also change the representation of LinkageLocation to use a BitField rather than using a reserved section of the integer range. Review URL: https://codereview.chromium.org/1262343002 Cr-Commit-Position: refs/heads/master@{#29938}
-
- 29 Apr, 2015 1 commit
-
-
dcarney authored
- allows the optimization of emitted gap move code since the representation of the value in the register is known - necessary preparation for vector register allocation - prepare for slot sharing for any value of the same byte width TBR=jarin@chromium.org BUG= Review URL: https://codereview.chromium.org/1111323003 Cr-Commit-Position: refs/heads/master@{#28140}
-