PPC: [wasm] Fixes for embedded constant pools.

PPC: [wasm] Fixes for embedded constant pools.

R=titzer@chromium.org, bradnelson@chromium.org, ahaas@chromium.org
BUG=

Committed: https://crrev.com/5312bfb9f3ecd09ebabd848dbf661e7326c84ef9
Cr-Commit-Position: refs/heads/master@{#33310}

[MTBrandyberry, 2016-01-11 18:10:04]

https://codereview.chromium.org/1575103002/diff/1/src/compiler/ppc/code-gener...
File src/compiler/ppc/code-generator-ppc.cc (right):

https://codereview.chromium.org/1575103002/diff/1/src/compiler/ppc/code-gener...
src/compiler/ppc/code-generator-ppc.cc:1552: __ StubPrologue();
wasm owners: Is there a condition would would detect compilation of an exported
wasm routine?  This change makes the prologue more expensive so would like to
limit if possible.

[MTBrandyberry, 2016-01-12 20:15:52]

Rebased... still looking for guidance on my original question.

[titzer, 2016-01-13 09:17:40]

https://codereview.chromium.org/1575103002/diff/20001/src/compiler/ppc/code-g...
File src/compiler/ppc/code-generator-ppc.cc (right):

https://codereview.chromium.org/1575103002/diff/20001/src/compiler/ppc/code-g...
src/compiler/ppc/code-generator-ppc.cc:1550: // the constant pool pointer
register.
To detect the compilation of a WASM function, you can get output_code_kind()
from the CompilationInfo, but I'm not sure that's the right check. I get crashes
on PPC for the WASM mjsunit tests (where the wrappers are compiled) in the
register allocator with and without this change. I dug a bit but I don't really
understand how IP is used in generated code.

[MTBrandyberry, 2016-01-13 15:09:34]

On 2016/01/13 09:17:40, titzer wrote:
>
https://codereview.chromium.org/1575103002/diff/20001/src/compiler/ppc/code-g...
> File src/compiler/ppc/code-generator-ppc.cc (right):
> 
>
https://codereview.chromium.org/1575103002/diff/20001/src/compiler/ppc/code-g...
> src/compiler/ppc/code-generator-ppc.cc:1550: // the constant pool pointer
> register.
> To detect the compilation of a WASM function, you can get output_code_kind()
> from the CompilationInfo, but I'm not sure that's the right check. I get
crashes
> on PPC for the WASM mjsunit tests (where the wrappers are compiled) in the
> register allocator with and without this change. I dug a bit but I don't
really
> understand how IP is used in generated code.

Thanks for this.  I think what I really need is something to indicate wasm
wrapper vs function generation.  As background, the JS call sequence on PPC
places the entrypoint address into ip which can then be used to easily calculate
the constant pool address.  For functions that can be called from C code, like
these wasm wrappers, we need to load the constant pool address in a more
expensive fashion since the native calling conventions don't provide the
entrypoint address in ip.

A similar issue exists for platforms using function descriptors.  The prologue
generation needs to recognize when the function can be called from C code and
generate a function descriptor prior to the prologue.

Is there any way to distinguish generation of a wasm wrapper from a wasm
function?

[titzer, 2016-01-14 16:52:03]

On 2016/01/13 15:09:34, mtbrandyberry wrote:
> On 2016/01/13 09:17:40, titzer wrote:
> >
>
https://codereview.chromium.org/1575103002/diff/20001/src/compiler/ppc/code-g...
> > File src/compiler/ppc/code-generator-ppc.cc (right):
> > 
> >
>
https://codereview.chromium.org/1575103002/diff/20001/src/compiler/ppc/code-g...
> > src/compiler/ppc/code-generator-ppc.cc:1550: // the constant pool pointer
> > register.
> > To detect the compilation of a WASM function, you can get output_code_kind()
> > from the CompilationInfo, but I'm not sure that's the right check. I get
> crashes
> > on PPC for the WASM mjsunit tests (where the wrappers are compiled) in the
> > register allocator with and without this change. I dug a bit but I don't
> really
> > understand how IP is used in generated code.
> 
> Thanks for this.  I think what I really need is something to indicate wasm
> wrapper vs function generation.  As background, the JS call sequence on PPC
> places the entrypoint address into ip which can then be used to easily
calculate
> the constant pool address.  For functions that can be called from C code, like
> these wasm wrappers, we need to load the constant pool address in a more
> expensive fashion since the native calling conventions don't provide the
> entrypoint address in ip.
> 
> A similar issue exists for platforms using function descriptors.  The prologue
> generation needs to recognize when the function can be called from C code and
> generate a function descriptor prior to the prologue.
> 
> Is there any way to distinguish generation of a wasm wrapper from a wasm
> function?

Yeah, you can checking the incoming call descriptor's UseNativeStack() versus
the outgoing call's UseNativeStack(), but that's only at the call position. Do
you want to check this at the prologue?

[MTBrandyberry, 2016-01-14 17:13:31]

On 2016/01/14 16:52:03, titzer wrote:
> On 2016/01/13 15:09:34, mtbrandyberry wrote:
> > On 2016/01/13 09:17:40, titzer wrote:
> > >
> >
>
https://codereview.chromium.org/1575103002/diff/20001/src/compiler/ppc/code-g...
> > > File src/compiler/ppc/code-generator-ppc.cc (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/1575103002/diff/20001/src/compiler/ppc/code-g...
> > > src/compiler/ppc/code-generator-ppc.cc:1550: // the constant pool pointer
> > > register.
> > > To detect the compilation of a WASM function, you can get
output_code_kind()
> > > from the CompilationInfo, but I'm not sure that's the right check. I get
> > crashes
> > > on PPC for the WASM mjsunit tests (where the wrappers are compiled) in the
> > > register allocator with and without this change. I dug a bit but I don't
> > really
> > > understand how IP is used in generated code.
> > 
> > Thanks for this.  I think what I really need is something to indicate wasm
> > wrapper vs function generation.  As background, the JS call sequence on PPC
> > places the entrypoint address into ip which can then be used to easily
> calculate
> > the constant pool address.  For functions that can be called from C code,
like
> > these wasm wrappers, we need to load the constant pool address in a more
> > expensive fashion since the native calling conventions don't provide the
> > entrypoint address in ip.
> > 
> > A similar issue exists for platforms using function descriptors.  The
prologue
> > generation needs to recognize when the function can be called from C code
and
> > generate a function descriptor prior to the prologue.
> > 
> > Is there any way to distinguish generation of a wasm wrapper from a wasm
> > function?
> 
> Yeah, you can checking the incoming call descriptor's UseNativeStack() versus
> the outgoing call's UseNativeStack(), but that's only at the call position. Do
> you want to check this at the prologue?

Yes, although it looks like UseNativeStack might get me what I need.  Let me
experiment.

I'd like to get this one landed and I'll refine further in another CL.

[titzer, 2016-01-14 17:30:59]

On 2016/01/14 17:13:31, mtbrandyberry wrote:
> On 2016/01/14 16:52:03, titzer wrote:
> > On 2016/01/13 15:09:34, mtbrandyberry wrote:
> > > On 2016/01/13 09:17:40, titzer wrote:
> > > >
> > >
> >
>
https://codereview.chromium.org/1575103002/diff/20001/src/compiler/ppc/code-g...
> > > > File src/compiler/ppc/code-generator-ppc.cc (right):
> > > > 
> > > >
> > >
> >
>
https://codereview.chromium.org/1575103002/diff/20001/src/compiler/ppc/code-g...
> > > > src/compiler/ppc/code-generator-ppc.cc:1550: // the constant pool
pointer
> > > > register.
> > > > To detect the compilation of a WASM function, you can get
> output_code_kind()
> > > > from the CompilationInfo, but I'm not sure that's the right check. I get
> > > crashes
> > > > on PPC for the WASM mjsunit tests (where the wrappers are compiled) in
the
> > > > register allocator with and without this change. I dug a bit but I don't
> > > really
> > > > understand how IP is used in generated code.
> > > 
> > > Thanks for this.  I think what I really need is something to indicate wasm
> > > wrapper vs function generation.  As background, the JS call sequence on
PPC
> > > places the entrypoint address into ip which can then be used to easily
> > calculate
> > > the constant pool address.  For functions that can be called from C code,
> like
> > > these wasm wrappers, we need to load the constant pool address in a more
> > > expensive fashion since the native calling conventions don't provide the
> > > entrypoint address in ip.
> > > 
> > > A similar issue exists for platforms using function descriptors.  The
> prologue
> > > generation needs to recognize when the function can be called from C code
> and
> > > generate a function descriptor prior to the prologue.
> > > 
> > > Is there any way to distinguish generation of a wasm wrapper from a wasm
> > > function?
> > 
> > Yeah, you can checking the incoming call descriptor's UseNativeStack()
versus
> > the outgoing call's UseNativeStack(), but that's only at the call position.
Do
> > you want to check this at the prologue?
> 
> Yes, although it looks like UseNativeStack might get me what I need.  Let me
> experiment.
> 
> I'd like to get this one landed and I'll refine further in another CL.

Ok, in that case I'll lgtm this and we can iterate. Checking UseNativeStack() is
a stop-gap measure; we should probably codify in the call descriptor the state
of the constant pool pointer somehow.

[MTBrandyberry, 2016-01-14 17:36:54]

The CQ bit was checked by mbrandy@us.ibm.com

[commit-bot: I haz the power, 2016-01-14 17:37:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1575103002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1575103002/40001

[commit-bot: I haz the power, 2016-01-14 18:30:39]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-01-14 18:31:02]

Description was changed from

==========
PPC: [wasm] Fixes for embedded constant pools.

R=titzer@chromium.org, bradnelson@chromium.org, ahaas@chromium.org
BUG=
==========

to

==========
PPC: [wasm] Fixes for embedded constant pools.

R=titzer@chromium.org, bradnelson@chromium.org, ahaas@chromium.org
BUG=

Committed: https://crrev.com/5312bfb9f3ecd09ebabd848dbf661e7326c84ef9
Cr-Commit-Position: refs/heads/master@{#33310}
==========

[commit-bot: I haz the power, 2016-01-14 18:31:03]

Patchset 3 (id:??) landed as
https://crrev.com/5312bfb9f3ecd09ebabd848dbf661e7326c84ef9
Cr-Commit-Position: refs/heads/master@{#33310}