[Subzero][MIPS32] Add argument handling in LowerCall

- This patch adds functionality to assign arguments to registers and stack in lowerCall().

- It supports only i32,i64 arguments right now. Support for   floating point and structure args will be added soon.

[mohit.bhakkad, 2016-05-30 11:57:26]

Description was changed from

==========
patch for lowercall


adding i64 argumrnt in call


[Subzero][MIPS32] lower call may 20

BUG=
==========

to

==========
- This patch adds functionality to assign arguments to registers and stack in
lowerCall().

- It supports only i32,i64 arguments right now. Support for   floating point and
structure args will be added soon.
==========

[mohit.bhakkad, 2016-05-30 14:33:46]

mohit.bhakkad@imgtec.com changed reviewers:
+ eholk@chromium.org, jpp@chromium.org, kschimpf@google.com,
stichnot@chromium.org

[Jim Stichnoth, 2016-05-31 16:37:45]

https://codereview.chromium.org/2021033002/diff/40001/src/IceRegistersMIPS32.h
File src/IceRegistersMIPS32.h (right):

https://codereview.chromium.org/2021033002/diff/40001/src/IceRegistersMIPS32....
src/IceRegistersMIPS32.h:94: return (RegNum ==
RegNumT::fixme(RegMIPS32::Reg_A0A1)) ? RegMIPS32::Reg_A0 : RegMIPS32::Reg_A2;
This seems fine as long as RegNum is A0A1 or A2A3, but not for V0V1, T0T1, T2T3,
etc.  Same comment below.

https://codereview.chromium.org/2021033002/diff/40001/src/IceRegistersMIPS32....
src/IceRegistersMIPS32.h:99: return (RegNum ==
RegNumT::fixme(RegMIPS32::Reg_A0A1)) ? RegMIPS32::Reg_A1 : RegMIPS32::Reg_A3;
80-col
(run "make -f Makefile.standalone format" to fix automatically)

https://codereview.chromium.org/2021033002/diff/40001/src/IceTargetLoweringMI...
File src/IceTargetLoweringMIPS32.cpp (right):

https://codereview.chromium.org/2021033002/diff/40001/src/IceTargetLoweringMI...
src/IceTargetLoweringMIPS32.cpp:82: const uint32_t MIPS32_STACK_ALIGNMENT_BYTES
= 16;
Can this be constexpr?

https://codereview.chromium.org/2021033002/diff/40001/src/IceTargetLoweringMI...
src/IceTargetLoweringMIPS32.cpp:131: GPRArgInitializer[i] =
RegNumT::fixme(RegMIPS32::Reg_A0 + i);
This CL introduces several new uses of fixme(), which is kind of unfortunate. 
Hopefully this is just an interim step until a table-driven approach is ready,
e.g. in the style of the ARM lowering.

https://codereview.chromium.org/1676123002 is where RegNumT and fixme() came
from.  The idea is to prevent, or at least clearly identify, cases where we
assuming a specific ordering of register enum values, for example:
  Reg_A0 < Reg_A1
  Reg_A0 + 1 == Reg_A1

Assumptions like this effectively prevent reordering enum values, which may be
desirable e.g. to influence register allocator behavior.

https://codereview.chromium.org/2021033002/diff/40001/src/IceTargetLoweringMI...
src/IceTargetLoweringMIPS32.cpp:1017: // TODO(mohit.bhakkad) : Handle arguments
of type other than ScalarIntegerType
80-col, and pay special attention that "make format" does the right thing here.

(Same comment a few lines down.)

https://codereview.chromium.org/2021033002/diff/40001/src/IceTargetLoweringMI...
src/IceTargetLoweringMIPS32.cpp:1034: Lo,
RegNumT::fixme(RegMIPS32::getI64PairFirstGPRNum(Reg))));
Can these two fixme() calls be removed?

[Jim Stichnoth, 2016-06-02 14:09:53]

https://codereview.chromium.org/2021033002/diff/60001/src/IceRegistersMIPS32.h
File src/IceRegistersMIPS32.h (right):

https://codereview.chromium.org/2021033002/diff/60001/src/IceRegistersMIPS32....
src/IceRegistersMIPS32.h:94: return (RegNum == RegMIPS32::Reg_A0A1) ?
RegMIPS32::Reg_A0
This is still a problem, I think.

It looks like getI64PairFirstGPRNum(Reg_V0V1) will return Reg_A2, which seems
wrong.

Do you think something like the following is right, until a table-driven
approach is ready?

  return fixme((unsigned(RegNum) - Reg_I64PAIR_First) * 2 + Reg_GPR_First);

[mohit.bhakkad, 2016-06-09 10:52:14]

Hi Jim,

- With this patch 64bit.pnacl.ll is failing due to liveliness error.
- But it looks like calling convention part in this patch is required by many
other things.
- So I have separated that part with https://codereview.chromium.org/2052793003/

[mohit.bhakkad, 2016-06-13 10:36:52]

I have messed up with the branch I was using for this patch badly, and I am yet
to 
learn "git cl" tool to create same branch. Also most of the part of this patch
is
already commited. So I am abandoning this patch, and creating a fresh lowercall
patch(https://codereview.chromium.org/2063653003) which also supports f32/f64.

[Jim Stichnoth, 2016-06-13 12:39:25]

On 2016/06/13 10:36:52, mohit.bhakkad wrote:
> I have messed up with the branch I was using for this patch badly, and I am
yet
> to 
> learn "git cl" tool to create same branch. Also most of the part of this patch
> is
> already commited. So I am abandoning this patch, and creating a fresh
lowercall
> patch(https://codereview.chromium.org/2063653003) which also supports f32/f64.

OK.

In the future, you could do something like this:

  git checkout -b my_new_branch origin/master
  git cl patch 2021033002

You can then continue working on the CL in my_new_branch, including the usual
"git pull --rebase" (or equivalent) to pull in any new commits to master.  You
lose any private branch history of course, but that's not usually a problem.