Subzero: Make -reg-use and -reg-exclude specific to register class.

Subzero: Make -reg-use and -reg-exclude specific to register class.

The main feature here is that when listing a register via the -reg-use or -reg-exclude option, we can limit the effect to a single register class, instead of applying it across all register classes.  Example:

  pnacl-sz -reg-use i32:eax,i32:ecx,i32:edx -reg-exclude f32:xmm0

Note that without the register class prefix, behavior is the same as before, specifically that the restriction applies to all register classes.

This requires a few high-level changes:

1. We need a mechanism to name *all* register classes, not just the standard ones that map to IceType values.

2. While we're at it, give standard types a more usable name, e.g. "v4i32" instead of "<4 x i32>".

3. Since we've commandeered ":" as the class/register token separator, we change ARM i64 register pair names from e.g. "r0:r1" to "r0r1".

The motivation is that for register allocator torture testing, we'd like to drastically restrict the registers available to e.g. the extensively-used i32 register class, while not overly restricting the seldom-used i32to8 register class (which reflects the set of i32 registers that may trivially truncate to i8).

BUG= none
R=kschimpf@google.com

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

[Jim Stichnoth, 2016-01-22 01:07:14]

Description was changed from

==========
Subzero: Make -reg-use and -reg-exclude specific to register class.

BUG= none
==========

to

==========
Subzero: Make -reg-use and -reg-exclude specific to register class.

The main feature here is that when listing a register via the -reg-use or
-reg-exclude option, we can limit the effect to a single register class, instead
of applying it across all register classes.  Example:

  pnacl-sz -reg-use i32:eax,i32:ecx,i32:edx -reg-exclude f32:xmm0

This requires a few high-level changes:

1. We need a mechanism to name *all* register classes, not just the standard
ones that map to IceType values.

2. While we're at it, give standard types a more usable name, e.g. "v4i32"
instead of "<4 x i32>".

3. Since we've commandeered ":" as the class/register token separator, we change
ARM i64 register pair names from e.g. "r0:r1" to "r0r1".

The motivation is that for register allocator torture testing, we'd like to
drastically restrict the registers available to e.g. the extensively-used i32
register class, while not overly restricting the seldom-used i32to8 register
class (which reflects the set of i32 registers that may trivially truncate to
i8).

BUG= none
==========

[Jim Stichnoth, 2016-01-22 01:08:23]

Description was changed from

==========
Subzero: Make -reg-use and -reg-exclude specific to register class.

The main feature here is that when listing a register via the -reg-use or
-reg-exclude option, we can limit the effect to a single register class, instead
of applying it across all register classes.  Example:

  pnacl-sz -reg-use i32:eax,i32:ecx,i32:edx -reg-exclude f32:xmm0

This requires a few high-level changes:

1. We need a mechanism to name *all* register classes, not just the standard
ones that map to IceType values.

2. While we're at it, give standard types a more usable name, e.g. "v4i32"
instead of "<4 x i32>".

3. Since we've commandeered ":" as the class/register token separator, we change
ARM i64 register pair names from e.g. "r0:r1" to "r0r1".

The motivation is that for register allocator torture testing, we'd like to
drastically restrict the registers available to e.g. the extensively-used i32
register class, while not overly restricting the seldom-used i32to8 register
class (which reflects the set of i32 registers that may trivially truncate to
i8).

BUG= none
==========

to

==========
Subzero: Make -reg-use and -reg-exclude specific to register class.

The main feature here is that when listing a register via the -reg-use or
-reg-exclude option, we can limit the effect to a single register class, instead
of applying it across all register classes.  Example:

  pnacl-sz -reg-use i32:eax,i32:ecx,i32:edx -reg-exclude f32:xmm0

Note that without the register class prefix, behavior is the same as before,
specifically that the restriction applies to all register classes.

This requires a few high-level changes:

1. We need a mechanism to name *all* register classes, not just the standard
ones that map to IceType values.

2. While we're at it, give standard types a more usable name, e.g. "v4i32"
instead of "<4 x i32>".

3. Since we've commandeered ":" as the class/register token separator, we change
ARM i64 register pair names from e.g. "r0:r1" to "r0r1".

The motivation is that for register allocator torture testing, we'd like to
drastically restrict the registers available to e.g. the extensively-used i32
register class, while not overly restricting the seldom-used i32to8 register
class (which reflects the set of i32 registers that may trivially truncate to
i8).

BUG= none
==========

[Jim Stichnoth, 2016-01-22 01:24:40]

stichnot@chromium.org changed reviewers:
+ eholk@chromium.org, jpp@chromium.org, kschimpf@google.com, sehr@chromium.org

[Karl, 2016-01-22 17:10:55]

https://codereview.chromium.org/1614273002/diff/20001/src/IceTargetLowering.cpp
File src/IceTargetLowering.cpp (right):

https://codereview.chromium.org/1614273002/diff/20001/src/IceTargetLowering.c...
src/IceTargetLowering.cpp:180: [&BadRegNames, RegNameToIndex, TypeToRegisterSet,
TypeToRegisterSetSize,
Why not just use [&] and let the compiler figure out what variables to capture?.

https://codereview.chromium.org/1614273002/diff/20001/src/IceTargetLowering.c...
src/IceTargetLowering.cpp:184: IceString RClass, RName;
I don't think our style allowed multiple variables in a declaration.

https://codereview.chromium.org/1614273002/diff/20001/src/IceTargetLoweringAR...
File src/IceTargetLoweringARM32.cpp (right):

https://codereview.chromium.org/1614273002/diff/20001/src/IceTargetLoweringAR...
src/IceTargetLoweringARM32.cpp:335: RegARM32::RCARM32_NUM, [](int32_t RegNum) ->
IceString {
Isn't using RegARM32::RCARM32_NUM dangerous? The function regClassString is only
defined for values < IceType_NUM (marked unreachable for all other values).

I would add: "assert(RegARM32::RCARM32_NUM == IceTYPE_Num)", so that a compiler
time error will happen if a new ARM register class is added.

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

https://codereview.chromium.org/1614273002/diff/20001/src/IceTargetLoweringMI...
src/IceTargetLoweringMIPS32.cpp:109: RCMIPS32_NUM, RegMIPS32::getRegName,
regClassString);
Like in the ARM case, I would add an assert here. That way if an RC class is
added, a compiler error will be generated and the developer will know to fix the
class string.

[Jim Stichnoth, 2016-01-22 19:02:17]

https://codereview.chromium.org/1614273002/diff/20001/src/IceTargetLowering.cpp
File src/IceTargetLowering.cpp (right):

https://codereview.chromium.org/1614273002/diff/20001/src/IceTargetLowering.c...
src/IceTargetLowering.cpp:180: [&BadRegNames, RegNameToIndex, TypeToRegisterSet,
TypeToRegisterSetSize,
On 2016/01/22 17:10:54, Karl wrote:
> Why not just use [&] and let the compiler figure out what variables to
capture?.

Sweet, I had no idea!

https://codereview.chromium.org/1614273002/diff/20001/src/IceTargetLowering.c...
src/IceTargetLowering.cpp:184: IceString RClass, RName;
On 2016/01/22 17:10:54, Karl wrote:
> I don't think our style allowed multiple variables in a declaration.

Not sure that style issue is actually addressed anywhere, but in any case I
separated it here, and also above (UseSet/ExcludeSet).

https://codereview.chromium.org/1614273002/diff/20001/src/IceTargetLoweringAR...
File src/IceTargetLoweringARM32.cpp (right):

https://codereview.chromium.org/1614273002/diff/20001/src/IceTargetLoweringAR...
src/IceTargetLoweringARM32.cpp:335: RegARM32::RCARM32_NUM, [](int32_t RegNum) ->
IceString {
On 2016/01/22 17:10:54, Karl wrote:
> Isn't using RegARM32::RCARM32_NUM dangerous? The function regClassString is
only
> defined for values < IceType_NUM (marked unreachable for all other values).
> 
> I would add: "assert(RegARM32::RCARM32_NUM == IceTYPE_Num)", so that a
compiler
> time error will happen if a new ARM register class is added.

Done - used a separate function a la x86, which should assert if you add a new
register class and forget to configure its display/filter string.

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

https://codereview.chromium.org/1614273002/diff/20001/src/IceTargetLoweringMI...
src/IceTargetLoweringMIPS32.cpp:109: RCMIPS32_NUM, RegMIPS32::getRegName,
regClassString);
On 2016/01/22 17:10:54, Karl wrote:
> Like in the ARM case, I would add an assert here. That way if an RC class is
> added, a compiler error will be generated and the developer will know to fix
the
> class string.

Done.

[Karl, 2016-01-22 19:17:52]

lgtm

[Jim Stichnoth, 2016-01-22 21:07:49]

Description was changed from

==========
Subzero: Make -reg-use and -reg-exclude specific to register class.

The main feature here is that when listing a register via the -reg-use or
-reg-exclude option, we can limit the effect to a single register class, instead
of applying it across all register classes.  Example:

  pnacl-sz -reg-use i32:eax,i32:ecx,i32:edx -reg-exclude f32:xmm0

Note that without the register class prefix, behavior is the same as before,
specifically that the restriction applies to all register classes.

This requires a few high-level changes:

1. We need a mechanism to name *all* register classes, not just the standard
ones that map to IceType values.

2. While we're at it, give standard types a more usable name, e.g. "v4i32"
instead of "<4 x i32>".

3. Since we've commandeered ":" as the class/register token separator, we change
ARM i64 register pair names from e.g. "r0:r1" to "r0r1".

The motivation is that for register allocator torture testing, we'd like to
drastically restrict the registers available to e.g. the extensively-used i32
register class, while not overly restricting the seldom-used i32to8 register
class (which reflects the set of i32 registers that may trivially truncate to
i8).

BUG= none
==========

to

==========
Subzero: Make -reg-use and -reg-exclude specific to register class.

The main feature here is that when listing a register via the -reg-use or
-reg-exclude option, we can limit the effect to a single register class, instead
of applying it across all register classes.  Example:

  pnacl-sz -reg-use i32:eax,i32:ecx,i32:edx -reg-exclude f32:xmm0

Note that without the register class prefix, behavior is the same as before,
specifically that the restriction applies to all register classes.

This requires a few high-level changes:

1. We need a mechanism to name *all* register classes, not just the standard
ones that map to IceType values.

2. While we're at it, give standard types a more usable name, e.g. "v4i32"
instead of "<4 x i32>".

3. Since we've commandeered ":" as the class/register token separator, we change
ARM i64 register pair names from e.g. "r0:r1" to "r0r1".

The motivation is that for register allocator torture testing, we'd like to
drastically restrict the registers available to e.g. the extensively-used i32
register class, while not overly restricting the seldom-used i32to8 register
class (which reflects the set of i32 registers that may trivially truncate to
i8).

BUG= none
R=kschimpf@google.com

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

[Jim Stichnoth, 2016-01-22 21:07:51]

Committed patchset #4 (id:60001) manually as
2544d4d2ef7e340664dc0748a5de966f0ee8ef08 (presubmit successful).