Subzero: Deterministically sort constant pool entries.

Subzero: Deterministically sort constant pool entries.

Otherwise, constant pools are emitted in hash table order, which can vary across systems.

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

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

[Jim Stichnoth, 2015-04-07 23:05:14]

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

[jvoung (off chromium), 2015-04-08 15:03:28]

lgtm

https://codereview.chromium.org/1069453003/diff/1/tests_lit/llvm2ice_tests/el...
File tests_lit/llvm2ice_tests/elf_container.ll (right):

https://codereview.chromium.org/1069453003/diff/1/tests_lit/llvm2ice_tests/el...
tests_lit/llvm2ice_tests/elf_container.ll:423: ; CHECK-NEXT:     Value: 0x10
a bit surprised that L$double$0 and $1 didn't switch places

[Jim Stichnoth, 2015-04-08 22:34:31]

https://codereview.chromium.org/1069453003/diff/1/tests_lit/llvm2ice_tests/el...
File tests_lit/llvm2ice_tests/elf_container.ll (right):

https://codereview.chromium.org/1069453003/diff/1/tests_lit/llvm2ice_tests/el...
tests_lit/llvm2ice_tests/elf_container.ll:423: ; CHECK-NEXT:     Value: 0x10
On 2015/04/08 15:03:28, jvoung wrote:
> a bit surprised that L$double$0 and $1 didn't switch places

(Note: For whatever reason (oversight?), .L$double$0 and .L$double$2 are
checked, but not .L$double$1.)

If you look as the -filetype=asm output (after this patch), you get:

	.section	.rodata.cst4,"aM",@progbits,4
	.align	4
.L$float$0:
	.long	0x80000000	# float -0.000000e+00
.L$float$1:
	.long	0x3f9d70a0	# float 1.230000e+00
	.section	.rodata.cst8,"aM",@progbits,8
	.align	8
.L$double$2:
	.quad	0xfff8000000000003	# double -nan
.L$double$1:
	.quad	0xfff7ffffffffffff	# double -nan
.L$double$0:
	.quad	0xffffffffffffffff	# double -nan

The values within each section are indeed sorted by bit representation, if you
squint hard enough and realize that the comparison function is memcmp() on the
little-endian representation.  Then I'm guessing that llvm-readobj is sorting
its dump output by Name.

However, this made me realize that this memcmp() based comparison function will
lead to different results when Subzero is run on a big-endian machine (if that's
even a thing these days).  So I changed it to use a bitcast style operation and
then compare using an integer type.

This once again changes the output order, such that the .long and .quad values
appear properly sorted.  Note that this gets obscured a bit in the llvm-readobj
output since these values are output little-endian.

[jvoung (off chromium), 2015-04-09 05:12:05]

On 2015/04/08 22:34:31, stichnot wrote:
>
https://codereview.chromium.org/1069453003/diff/1/tests_lit/llvm2ice_tests/el...
> File tests_lit/llvm2ice_tests/elf_container.ll (right):
> 
>
https://codereview.chromium.org/1069453003/diff/1/tests_lit/llvm2ice_tests/el...
> tests_lit/llvm2ice_tests/elf_container.ll:423: ; CHECK-NEXT:     Value: 0x10
> On 2015/04/08 15:03:28, jvoung wrote:
> > a bit surprised that L$double$0 and $1 didn't switch places
> 
> (Note: For whatever reason (oversight?), .L$double$0 and .L$double$2 are
> checked, but not .L$double$1.)
> 
> If you look as the -filetype=asm output (after this patch), you get:
> 
> 	.section	.rodata.cst4,"aM",@progbits,4
> 	.align	4
> .L$float$0:
> 	.long	0x80000000	# float -0.000000e+00
> .L$float$1:
> 	.long	0x3f9d70a0	# float 1.230000e+00
> 	.section	.rodata.cst8,"aM",@progbits,8
> 	.align	8
> .L$double$2:
> 	.quad	0xfff8000000000003	# double -nan
> .L$double$1:
> 	.quad	0xfff7ffffffffffff	# double -nan
> .L$double$0:
> 	.quad	0xffffffffffffffff	# double -nan
> 
> The values within each section are indeed sorted by bit representation, if you
> squint hard enough and realize that the comparison function is memcmp() on the
> little-endian representation.  Then I'm guessing that llvm-readobj is sorting
> its dump output by Name.

Ah, ok yeah the little-endian threw me off.

> 
> However, this made me realize that this memcmp() based comparison function
will
> lead to different results when Subzero is run on a big-endian machine (if
that's
> even a thing these days).  So I changed it to use a bitcast style operation
and
> then compare using an integer type.
> 
> This once again changes the output order, such that the .long and .quad values
> appear properly sorted.  Note that this gets obscured a bit in the
llvm-readobj
> output since these values are output little-endian.

Ok still LGTM

[Jim Stichnoth, 2015-04-09 16:11:21]

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