- Don't bake in length/capacity into full codegen calls of stubs,
allowing boilerplates to increase their capacity without regenerating
code.
- Unify all variants of the clone stub into a single,
length-independent version.
- Various tweaks to make sure that the clone stub doesn't spill and
therefore need an eager stack frame.
- Handle all lengths of array literals in the fast case.
R=mvstanton@chromium.org
Review URL: https://codereview.chromium.org/272513004
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21230 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
[2nd try, after the previous version broke the build]
Currently, this code will compile:
SomePointer* p = ...;
ReturnValue r = ...;
r.Set(p);
What happens is that ReturnValue::Set has no pointer-ish overloads, but
a bool one, and hence C++ will convert the pointer to a bool and use
the Set(bool) overload. In other words, the example above is equivalent
to: r.Set(p ? true : false); Which probably isn't what the author had
in mind. This change adds a Set(void*) overload whose body forces a
compile error, to prevent this from happening inadvertently. The only
use of this indeed turned out to be an error.
(Said error was fixed/removed in crrev.com/267393002.)
Why was crrev.com/240013004 reverted?
The orginal version compiled fine on gcc (+ MSVC), but not on clang.
There's no clang try-bots, but the ASAN-based buildbots used clang
and hence the build broke. I'm slightly unsure on why, but clang -
unlike those other compilers - eagerly compiled the non-compilable
setter, which predictably broke. Now, the non-compilable setter uses
the same template logic that all other, comparable cases use. I've
tried 'make qc' with both gcc and clang versions.
BUG=
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/279883002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21228 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Even although the Arm64 specification specifies that csp
only needs to be aligned to 16 bytes if it is dereferenced, some
implementations show poor performance.
Also makes the following change:
- Enable CPU support for arm64 to enable probing of cpu implementer and cpu part.
- Add ALWAYS_ALIGN_CSP CpuFeature for Arm64 and set it based on runtime probing of the cpu imp
- Rename PrepareForPush and PrepareForPop to PushPreamble and PopPostamble and move PopPostabl
Original Review URL: https://codereview.chromium.org/264773004R=ulan@chromium.org
Review URL: https://codereview.chromium.org/271543004
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21221 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Reason for revert:
Looks like this broke the "V8 Linux64 ASAN" build.
Original issue's description:
> Prevent calls to ReturnValue::Set with pointer-valued types.
>
> Currently, this code will compile:
> SomePointer* p = ...;
> ReturnValue r = ...;
> r.Set(p);
>
> What happens is that ReturnValue::Set has no pointer-ish overloads, but
> a bool one, and hence C++ will convert the pointer to a bool and use
> the Set(bool) overload. In other words, the example above is equivalent
> to: r.Set(p ? true : false); Which probably isn't what the author had
> in mind. This change adds a Set(void*) overload whose body forces a
> compile error, to prevent this from happening inadvertently. The only
> use of this indeed turned out to be an error.
>
> (Said error was fixed/removed in crrev.com/267393002.)
>
> BUG=
> R=dcarney@chromium.org
>
> Committed: https://code.google.com/p/v8/source/detail?r=21217R=ishell@chromium.org
Review URL: https://codereview.chromium.org/271113002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21219 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Currently, this code will compile:
SomePointer* p = ...;
ReturnValue r = ...;
r.Set(p);
What happens is that ReturnValue::Set has no pointer-ish overloads, but
a bool one, and hence C++ will convert the pointer to a bool and use
the Set(bool) overload. In other words, the example above is equivalent
to: r.Set(p ? true : false); Which probably isn't what the author had
in mind. This change adds a Set(void*) overload whose body forces a
compile error, to prevent this from happening inadvertently. The only
use of this indeed turned out to be an error.
(Wait for issue 364025 before submitting.)
BUG=
R=dcarney@chromium.org
Review URL: https://codereview.chromium.org/240013004
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21217 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Rename Debug::MaybeRecompileFunctionForDebugging to
EnsureFunctionHasDebugBreakSlots and ensure that it does
nothing if the function is unoptimized code with debug
break slots, otherwise, if the shared code has no
debug break slots, it recompile that shared code and
sets the function code to that shared code.
Also removes two incorrect ASSERTs.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/271873003
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21201 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
r21177 added extra AssertStackConsistency() checks which
increased code size on debug and caused the assembler buffer
to be too large. Increased some of these buffers to
compensate.
Also, ProfileEntryHoolStub could use the wrong number of
instructions for kProfileEntryHookCallSize depending upon
whether debug code was being emitted or ALWAYS_ALIGN_CSP was
enabled. Fixed this by taking ALWAYS_ALIGN_CSP into account
and ensuring that no debug code is emitted during
MaybeCallEntryHook().
TBR=ulan@chromium.org
Review URL: https://codereview.chromium.org/263213008
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21179 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
