This is an archive of the discontinued LLVM Phabricator instance.

CodeGet: Init 32bit pointers with 0xFFFFFFFF
ClosedPublic

Authored by vitalybuka on Jul 11 2019, 2:13 PM.

Details

Summary

Patch makes D63967 effective for 32bit platforms and improves pattern
initialization there. It cuts size of 32bit binary compiled with
-ftrivial-auto-var-init=pattern by 2% (3% with -Os).

Binary size change on CTMark, (with -fuse-ld=lld -Wl,--icf=all, similar results with default linker options)

                   master           patch      diff
Os pattern   7.915580e+05    7.698424e+05 -0.028387 
O3 pattern   9.953688e+05    9.752952e+05 -0.019325

Zero vs Pattern on master

               zero       pattern      diff
Os     7.689712e+05  7.915580e+05  0.031380
O3     9.744796e+05  9.953688e+05  0.021133

Zero vs Pattern with the patch

               zero       pattern      diff
Os     7.689712e+05  7.698424e+05  0.000789
O3     9.744796e+05  9.752952e+05  0.000742

Event Timeline

vitalybuka created this revision.Jul 11 2019, 2:13 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 11 2019, 2:13 PM
pcc added a comment.Jul 11 2019, 2:27 PM

The problem with 0xaaaaaaaa on 32-bit is that it is likely to be a valid address.

When I discussed this with JF I proposed a pointer initialization of 0xffffffff which he agreed to. This value is very likely to trap when accessed (due to accesses likely wrapping to zero) and also has the benefit of being the same pattern as for floats.

jfb added a comment.Jul 11 2019, 2:43 PM
In D64597#1581605, @pcc wrote:

The problem with 0xaaaaaaaa on 32-bit is that it is likely to be a valid address.

When I discussed this with JF I proposed a pointer initialization of 0xffffffff which he agreed to. This value is very likely to trap when accessed (due to accesses likely wrapping to zero) and also has the benefit of being the same pattern as for floats.

Indeed.

vitalybuka retitled this revision from CodeGet: Init 32bit pointers with 0xAAAAAAAA to CodeGet: Init 32bit pointers with 0xFFFFFFFF.Jul 11 2019, 7:11 PM
vitalybuka edited the summary of this revision. (Show Details)
In D64597#1581654, @jfb wrote:
In D64597#1581605, @pcc wrote:

The problem with 0xaaaaaaaa on 32-bit is that it is likely to be a valid address.

When I discussed this with JF I proposed a pointer initialization of 0xffffffff which he agreed to. This value is very likely to trap when accessed (due to accesses likely wrapping to zero) and also has the benefit of being the same pattern as for floats.

Indeed.

Done. This is even more effective.
Maybe we should consider 0xAA for floats on 64bit?

undo unrelated line

jfb accepted this revision.Jul 12 2019, 9:19 AM
This revision is now accepted and ready to land.Jul 12 2019, 9:19 AM
In D64597#1581605, @pcc wrote:

The problem with 0xaaaaaaaa on 32-bit is that it is likely to be a valid address.

When I discussed this with JF I proposed a pointer initialization of 0xffffffff which he agreed to. This value is very likely to trap when accessed (due to accesses likely wrapping to zero) and also has the benefit of being the same pattern as for floats.

The value is very likely not to trap on some systems (due to accesses likely wrapping to zero). I am not sure I have a better magic value to offer though.

pcc added a comment.Jul 12 2019, 9:42 AM
In D64597#1581605, @pcc wrote:

The problem with 0xaaaaaaaa on 32-bit is that it is likely to be a valid address.

When I discussed this with JF I proposed a pointer initialization of 0xffffffff which he agreed to. This value is very likely to trap when accessed (due to accesses likely wrapping to zero) and also has the benefit of being the same pattern as for floats.

The value is very likely not to trap on some systems (due to accesses likely wrapping to zero). I am not sure I have a better magic value to offer though.

Right, though if your zero page is mapped then 0xffffffff is probably as good as 0x000000aa.

jfb added a comment.Jul 12 2019, 9:43 AM
In D64597#1581605, @pcc wrote:

The problem with 0xaaaaaaaa on 32-bit is that it is likely to be a valid address.

When I discussed this with JF I proposed a pointer initialization of 0xffffffff which he agreed to. This value is very likely to trap when accessed (due to accesses likely wrapping to zero) and also has the benefit of being the same pattern as for floats.

The value is very likely not to trap on some systems (due to accesses likely wrapping to zero). I am not sure I have a better magic value to offer though.

On 32-bit platforms the only region that's likely to trap is the zero page. This seems to be the best choice, but platforms with other regions should be able to tune this value (i.e. I'd accept platform checks here which change the value on such a target).

In D64597#1582950, @jfb wrote:

On 32-bit platforms the only region that's likely to trap is the zero page. This seems to be the best choice, but platforms with other regions should be able to tune this value (i.e. I'd accept platform checks here which change the value on such a target).

Sounds good. If I get more information from my internal inquiries, then we'll follow up in a later patch. Thanks.

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJul 12 2019, 10:21 AM