emitIAS for Shld and Shrd and the ternary and three-address ops.

emitIAS for Shld and Shrd and the ternary and three-address ops.

Give a different name to the crosstest .s and .o files depending on the
CPU features as well. That way the SSE2 and SSE4.1 .s and .o are separate.

The encodings for Pextrw and Pextrb/d... make me sad.

BUG=none
R=stichnot@chromium.org

Committed: https://gerrit.chromium.org/gerrit/gitweb?p=native_client/pnacl-subzero.git;a=commit;h=962befa4684fabfcc49742cef605f0e8c7372dde

[jvoung (off chromium), 2014-10-15 00:27:57]

jvoung@chromium.org changed reviewers:
+ stichnot@chromium.org

[Jim Stichnoth, 2014-10-15 02:09:28]

lgtm

https://codereview.chromium.org/656983002/diff/20001/src/IceInstX8632.cpp
File src/IceInstX8632.cpp (right):

https://codereview.chromium.org/656983002/diff/20001/src/IceInstX8632.cpp#new...
src/IceInstX8632.cpp:2337: // them all to have a register dest for now.
Just wondering if you've thought about what happens if down the road we start
trying to generate these kinds of not-yet-supported instructions?  I guess we
can impose temporary restrictions in the lowering code via legalize(), or in the
peephole optimizations or whatever, until the support is there?

[jvoung (off chromium), 2014-10-15 16:23:44]

https://codereview.chromium.org/656983002/diff/20001/src/IceInstX8632.cpp
File src/IceInstX8632.cpp (right):

https://codereview.chromium.org/656983002/diff/20001/src/IceInstX8632.cpp#new...
src/IceInstX8632.cpp:2337: // them all to have a register dest for now.
On 2014/10/15 02:09:27, stichnot wrote:
> Just wondering if you've thought about what happens if down the road we start
> trying to generate these kinds of not-yet-supported instructions?  I guess we
> can impose temporary restrictions in the lowering code via legalize(), or in
the
> peephole optimizations or whatever, until the support is there?


I think we would have to impose some legalizations temporarily, yes. I'm not
sure how that would work if there was a big change in lowering though, so it
could end up being a separate pass =(

Otherwise, I can try to prepare for switches by at least adding the
assembler_ia32.h/cpp functions (but not used). I think the linker could help us
prune the functions that aren't used, but will have to check again.

We are okay for most of the XMM ones, because they tend to only support dest ==
reg in the encodings.

We'll have some problems in some cases like this, and for some of the GPR
binops. The GPR binops we can handle more quickly, because they mostly go
through the common emit function. The common emit function could be changed to
be more like Icmp where it has dispatching for dest == mem. The slow work is in
adding all the assembler_ia32.h/cpp functions, I think.

[jvoung (off chromium), 2014-10-15 16:33:03]

Committed patchset #2 (id:20001) manually as
962befa4684fabfcc49742cef605f0e8c7372dde (presubmit successful).

[Jim Stichnoth, 2014-10-15 16:45:59]

https://codereview.chromium.org/656983002/diff/20001/src/IceInstX8632.cpp
File src/IceInstX8632.cpp (right):

https://codereview.chromium.org/656983002/diff/20001/src/IceInstX8632.cpp#new...
src/IceInstX8632.cpp:2337: // them all to have a register dest for now.
On 2014/10/15 16:23:43, jvoung wrote:
> On 2014/10/15 02:09:27, stichnot wrote:
> > Just wondering if you've thought about what happens if down the road we
start
> > trying to generate these kinds of not-yet-supported instructions?  I guess
we
> > can impose temporary restrictions in the lowering code via legalize(), or in
> the
> > peephole optimizations or whatever, until the support is there?
> 
> 
> I think we would have to impose some legalizations temporarily, yes. I'm not
> sure how that would work if there was a big change in lowering though, so it
> could end up being a separate pass =(
> 
> Otherwise, I can try to prepare for switches by at least adding the
> assembler_ia32.h/cpp functions (but not used). I think the linker could help
us
> prune the functions that aren't used, but will have to check again.
> 
> We are okay for most of the XMM ones, because they tend to only support dest
==
> reg in the encodings.
> 
> We'll have some problems in some cases like this, and for some of the GPR
> binops. The GPR binops we can handle more quickly, because they mostly go
> through the common emit function. The common emit function could be changed to
> be more like Icmp where it has dispatching for dest == mem. The slow work is
in
> adding all the assembler_ia32.h/cpp functions, I think.

After writing my comment, I convinced myself that we will be fine and legalize()
can work around until the encoding is available.  Similar things have happened,
e.g. working around the llvm-mc lea bug.

As long as ias has reasonable assertions, it should probably be fine.