- 27 Nov, 2015 1 commit
-
-
jochen authored
BUG=v8:2487 R=yangguo@chromium.org,jkummerow@chromium.org,mstarzinger@chromium.org LOG=n Review URL: https://codereview.chromium.org/1474763008 Cr-Commit-Position: refs/heads/master@{#32359}
-
- 30 Sep, 2015 1 commit
-
-
mstarzinger authored
This enables linter checking for "readability/namespace" violations during presubmit and instead marks the few known exceptions that we allow explicitly. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1371083003 Cr-Commit-Position: refs/heads/master@{#31019}
-
- 15 May, 2015 1 commit
-
-
martyn.capewell authored
Enable clang's shorten-64-to-32 warning flag on ARM64, and fix the warnings that arise. BUG= Review URL: https://codereview.chromium.org/1131573006 Cr-Commit-Position: refs/heads/master@{#28412}
-
- 19 Mar, 2015 1 commit
-
-
rodolph.perfetta authored
BUG= Review URL: https://codereview.chromium.org/1016073002 Cr-Commit-Position: refs/heads/master@{#27296}
-
- 11 Sep, 2014 1 commit
-
-
baptiste.afsa@arm.com authored
R=bmeurer@chromium.org, ulan@chromium.org BUG= Review URL: https://codereview.chromium.org/559073003 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23856 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Sep, 2014 1 commit
-
-
Jacob.Bramley@arm.com authored
- Use standard names (except that our GREY is the standard BLACK). - Make non-bold colours explicit, otherwise the boldness can carry over into subsequent colour declarations. - I've moved some colours around to make them consistent. Register value updates (which are very common) now stand out less than they did, making the less-common (and arguably more important) debug announcements appear brighter. - FP registers and values are now magenta. - Integer registers and values are now cyan. - Memory accesses are now blue. - LOG_WRITE prints the source register for stores. - Loads are logged with a format similar to that used for stores. Specifically, the memory address is printed alongside the new register value. - Updates to D registers print the raw bits as well as the double value. Updates to S registers print the raw bits as well as the float value. (Previously, we printed both double and float interpretations of the bits, which was a bit cluttered.) BUG= R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/551823004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23802 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Sep, 2014 1 commit
-
-
svenpanne@chromium.org authored
Revert r23732 ("ARM64: Fix and improve --trace-sim register trace.") and r23733 ("ARM64: Fix build warning in r23732.) They break the build when compiling with optimizations, e.g. optdebug: ../src/arm64/simulator-arm64.cc: In member function ‘void v8::internal::Simulator::PrintWriteFP(uintptr_t, size_t, unsigned int)’: ../src/arm64/simulator-arm64.cc:792:29: error: array subscript is above array bounds [-Werror=array-bounds] ../src/arm64/simulator-arm64.cc:799:29: error: array subscript is above array bounds [-Werror=array-bounds] TBR=yangguo@chromium.org Review URL: https://codereview.chromium.org/549083004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23765 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Sep, 2014 1 commit
-
-
Jacob.Bramley@arm.com authored
- Use standard names (except that our GREY is the standard BLACK). - Make non-bold colours explicit, otherwise the boldness can carry over into subsequent colour declarations. - I've moved some colours around to make them consistent. Register value updates (which are very common) now stand out less than they did, making the less-common (and arguably more important) debug announcements appear brighter. - FP registers and values are now magenta. - Integer registers and values are now cyan. - Memory accesses are now blue. - LOG_WRITE prints the source register for stores. - Loads are logged with a format similar to that used for stores. Specifically, the memory address is printed alongside the new register value. - Updates to D registers print the raw bits as well as the double value. Updates to S registers print the raw bits as well as the float value. (Previously, we printed both double and float interpretations of the bits, which was a bit cluttered.) BUG= R=ulan@chromium.org Review URL: https://codereview.chromium.org/548473002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23732 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Aug, 2014 1 commit
-
-
bmeurer@chromium.org authored
This way we don't clash with the ASSERT* macros defined by GoogleTest, and we are one step closer to being able to replace our homegrown base/ with base/ from Chrome. R=jochen@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/430503007 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22812 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Jun, 2014 1 commit
-
-
mstarzinger@chromium.org authored
R=rossberg@chromium.org Review URL: https://codereview.chromium.org/333013002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21894 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Jun, 2014 1 commit
-
-
rodolph.perfetta@arm.com authored
This is the first patch to improve literal pool handling in arm64. Cleans up assembler/macro-assembler access to literal pools. BUG= R=rmcilroy@chromium.org Review URL: https://codereview.chromium.org/318773009 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21723 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jun, 2014 1 commit
-
-
jochen@chromium.org authored
- this avoids using relative include paths which are forbidden by the style guide - makes the code more readable since it's clear which header is meant - allows for starting to use checkdeps BUG=none R=jkummerow@chromium.org, danno@chromium.org LOG=n Review URL: https://codereview.chromium.org/304153016 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 May, 2014 1 commit
-
-
Jacob.Bramley@arm.com authored
- W-sized values passed to Printf are now handled correctly by the simulator. In AAPCS64, int32_t and int64_t are passed in the same way, so this didn't affect non-simulator builds. - Since Printf now records the type and size of each argument, it is possible to mix argument types. - It is now possible to print the stack pointer. There is only one remaining restriction: The `csp` register cannot be printed unless it is the current stack pointer. This is because it is modified by BumpSystemStackPointer when the caller-saved registers are preserved. BUG= R=rmcilroy@chromium.org Review URL: https://codereview.chromium.org/268353005 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21272 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Apr, 2014 1 commit
-
-
bmeurer@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/259183002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 14 Apr, 2014 1 commit
-
-
alexandre.rames@arm.com authored
Instead, inspect the label chain and delete pending information for every branch in the chain. R=ulan@chromium.org Review URL: https://codereview.chromium.org/227043010 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20715 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Apr, 2014 1 commit
-
-
alexandre.rames@arm.com authored
This fixes an out-of-range label error for an ADR instruction in the mozilla/data/js1_5/Regress/regress-280769-2.js test. R=ulan@chromium.org Review URL: https://codereview.chromium.org/222433002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20545 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Mar, 2014 1 commit
-
-
jochen@chromium.org authored
BUG=354405 R=ulan@chromium.org, rodolph.perfetta@arm.com LOG=y Review URL: https://codereview.chromium.org/207823003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20148 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Mar, 2014 1 commit
-
-
svenpanne@chromium.org authored
We no longer rely on the (adventurous) assumption that the class Instruction is empty, implying sizeof(Instruction) == 1. This will greatly simplify upcoming refactorings. R=rodolph.perfetta@gmail.com Review URL: https://codereview.chromium.org/201843003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20018 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 14 Mar, 2014 2 commits
-
-
svenpanne@chromium.org authored
The addresses involved should always be aligned, so we can simply use a cast, just like the ARM simulator. Even if the alignment assumption did not hold and the platform we are running on couldn't handle unaligned access, some #ifdefs would be much more preferable. The affected member functions were the top 2 in a profile (18% and 15%), so basically every hack is allowed here to speed things up. :-) Removed some dead code for literals on the way. If we need to resurrect it, we should do it without double(!) memcpys. Generally, I still don't understand why we need the Instr/Instruction distinction or simply wrap Instr within Instruction, this seems to be much simpler and cleaner, but this would involve heavier changes. The overall speedup of this CL is roughly 37%, see the numbers below for a reduced Octane suite and the check targets: ------------------------------------------------------------ With memcpy: ------------------------------------------------------------ make -j32 a64.release.quickcheck => 03:29 make -j32 a64.release.check => 11:30 Reduced Octane suite => 05:16 Richards: 35.1 DeltaBlue: 64.1 RayTrace: 130 Splay: 66.1 SplayLatency: 619 NavierStokes: 58.7 PdfJS: 89.6 Mandreel: 58.5 MandreelLatency: 242 CodeLoad: 5103 Box2D: 124 ---- Score (version 9): 144 ------------------------------------------------------------ With casts: ------------------------------------------------------------ make -j32 a64.release.quickcheck => 02:14 make -j32 a64.release.check => 07:21 Reduced Octane suite => 03:21 Richards: 53.3 DeltaBlue: 103 RayTrace: 205 Splay: 95.9 SplayLatency: 859 NavierStokes: 103 PdfJS: 136 Mandreel: 94.8 MandreelLatency: 386 CodeLoad: 6493 Box2D: 179 ---- Score (version 9): 219 R=ulan@chromium.org Review URL: https://codereview.chromium.org/195873009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19929 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
jacob.bramley@arm.com authored
- Return the correct NaN when an invalid operation generates a NaN. - When one or more operands are NaN, handle them as the processor would, prioritising signalling NaNs and making them quiet. - Fix fmadd and related instructions: - Fnmadd is fma(-n, m, -a), not -fma(n, m, a). - Some common libc implementations incorrectly implement fma for zero results, so work around these cases. - Replace some unreliable tests. This patch also adds support for Default-NaN mode, since once all the other work was done, it only required a couple of lines of code. Default-NaN mode was used for an optimisation in ARM, and it should now be possible to apply the same optimisation to A64. BUG= R=jochen@chromium.org Review URL: https://codereview.chromium.org/199083005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19927 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Feb, 2014 1 commit
-
-
alexandre.rames@arm.com authored
Code generation would fail when assembling a branch to a label that is bound outside the immediate range of the instruction. A64 is sensitive to this, as the various branching instructions have different ranges, going down to +-32KB for TBZ/TBNZ. The MacroAssembler is augmented to handle branches to targets that may exceed the immediate range of instructions. When branching backward to a label exceeding the instruction range, the MacroAssembler can simply tweak the generated code to use an unconditional branch with a longer range. For example instead of B(cond, &label); the MacroAssembler can generate: b(InvertCondition(cond), &done); b(&label); bind(&done); Since the target is not known when the branch is emitted, forward branches uses a different mechanism. The MacroAssembler keeps track of forward branches to unbound labels. When the code generation approaches the end of the range of a branch, a veneer is generated for the branch. BUG=v8:3148 LOG=Y R=ulan@chromium.org Review URL: https://codereview.chromium.org/169893002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19444 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Feb, 2014 1 commit
-
-
ulan@chromium.org authored
BUG=v8:3113 LOG=Y R=jochen@chromium.org, rmcilroy@chromium.org, rodolph.perfetta@arm.com Review URL: https://codereview.chromium.org/148293020 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19311 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-