Change usage of naclcall and nacljmp pseudo-instructions to match x86 gas

Change usage of naclcall and nacljmp pseudo-instructions to match x86 gas

x86 gas uses "call" for direct calls and "naclcall" for indirect calls,
and implicitly handles bundle-align-to-end for all calls in nacl mode;
previously we used "naclcall" for all calls which used bundle alignment.
This makes the assembler automatically align bare "call"
instructions. On x86-32 we remove our custom nacl-flavored
call instruction in favor of the bare call. On x86-64 we
still need a different codegen target for isel that takes
a 32-bit operand due to our pointer-size differences,
but we also sandbox bare call instructions.

Also for 64-bit forms of "nacljmp %foo, %r15" gas uses 32-bit operands
(nacljmp %r11d, %r15), whereas we had been using 64-bit operands
(nacljmp %r11, %r15). Using a 32-bit operand makes some sense since
the pointers are 32 bits; using a 64-bit operand makes some sense since
the entire register is cleared, but it's better to match. The operands
used in codegen are the same so again this is mostly just a change in
assembler spelling that's invisible to the compiler.

R=jvoung@chromium.org
BUG= https://code.google.com/p/nativeclient/issues/detail?id=3966

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

[Derek Schuff, 2014-10-14 00:04:34]

I had hoped to get rid of 
NACL_CALL32d and replace it with just CALLpcrel32, but that didn't work when
using the integrated assembler because
having CustomExpandInstNaClX86 handle "normal" opcodes results in infinite
recursion.

I had hoped to do the same for 64-bit, but it had the additional problem that
the normal call CALL64pcrel32 takes a 64-bit operand instead of a 32-bit operand
so we still need separate codegen targets for isel pattern matching.

The former problem would be fairly straightforward to fix but we might want to
make a more general change that takes us in the direction of auto-sandboxing;
i'll have to think about that. Although I may do something shorter-term anyway
if we want the integrated assembler to work with .s files (it doesn't right now,
for other reasons).

[jvoung (off chromium), 2014-10-14 15:30:24]

https://codereview.chromium.org/647443005/diff/1/lib/Target/X86/X86InstrNaCl.td
File lib/Target/X86/X86InstrNaCl.td (right):

https://codereview.chromium.org/647443005/diff/1/lib/Target/X86/X86InstrNaCl....
lib/Target/X86/X86InstrNaCl.td:64: "call\t$dst">;
How does this affect the asm parser, if someone was to use llvm-mc? Would it
have trouble deciding between NACL_CALL32d and CALLpcrel32?

[Derek Schuff, 2014-10-14 23:39:32]

https://codereview.chromium.org/647443005/diff/1/lib/Target/X86/X86InstrNaCl.td
File lib/Target/X86/X86InstrNaCl.td (right):

https://codereview.chromium.org/647443005/diff/1/lib/Target/X86/X86InstrNaCl....
lib/Target/X86/X86InstrNaCl.td:64: "call\t$dst">;
On 2014/10/14 15:30:23, jvoung wrote:
> How does this affect the asm parser, if someone was to use llvm-mc? Would it
> have trouble deciding between NACL_CALL32d and CALLpcrel32?

I had thought that it would work by making CALLpcrel32 requires<NotNaCl> but
apparently that doesn't work with the asm parser.
So I went back to my previous idea of removing NACL_CALL32d and fixing up the
recursion behavior of CustomExpandInstNaClX86; PTAL

[jvoung (off chromium), 2014-10-15 00:38:14]

LGTM

https://codereview.chromium.org/647443005/diff/20001/lib/Target/X86/X86InstrN...
File lib/Target/X86/X86InstrNaCl.td (right):

https://codereview.chromium.org/647443005/diff/20001/lib/Target/X86/X86InstrN...
lib/Target/X86/X86InstrNaCl.td:106: "call\t$dst">;
Hmm, interesting -- is there no problem w/ this because the type of the
immediate doesn't clash with CALL64pcrel32 ?

https://codereview.chromium.org/647443005/diff/20001/lib/Target/X86/X86NaClRe...
File lib/Target/X86/X86NaClRewritePass.cpp (right):

https://codereview.chromium.org/647443005/diff/20001/lib/Target/X86/X86NaClRe...
lib/Target/X86/X86NaClRewritePass.cpp:629: //   naclcall __nacl_read_tp@PLT
"call __nacl_read_tp" now?

https://codereview.chromium.org/647443005/diff/20001/lib/Target/X86/X86NaClRe...
lib/Target/X86/X86NaClRewritePass.cpp:658: //   naclcall __nacl_read_tp@PLT
same

[Derek Schuff, 2014-10-15 17:14:00]

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

[Derek Schuff, 2014-10-15 17:14:14]

https://codereview.chromium.org/647443005/diff/20001/lib/Target/X86/X86InstrN...
File lib/Target/X86/X86InstrNaCl.td (right):

https://codereview.chromium.org/647443005/diff/20001/lib/Target/X86/X86InstrN...
lib/Target/X86/X86InstrNaCl.td:106: "call\t$dst">;
On 2014/10/15 00:38:14, jvoung wrote:
> Hmm, interesting -- is there no problem w/ this because the type of the
> immediate doesn't clash with CALL64pcrel32 ?

No, there doesn't seem to be; I assume that's the reason why.

https://codereview.chromium.org/647443005/diff/20001/lib/Target/X86/X86NaClRe...
File lib/Target/X86/X86NaClRewritePass.cpp (right):

https://codereview.chromium.org/647443005/diff/20001/lib/Target/X86/X86NaClRe...
lib/Target/X86/X86NaClRewritePass.cpp:629: //   naclcall __nacl_read_tp@PLT
On 2014/10/15 00:38:14, jvoung wrote:
> "call __nacl_read_tp" now?

Done.

https://codereview.chromium.org/647443005/diff/20001/lib/Target/X86/X86NaClRe...
lib/Target/X86/X86NaClRewritePass.cpp:658: //   naclcall __nacl_read_tp@PLT
On 2014/10/15 00:38:14, jvoung wrote:
> same

Done.