[PATCH] D27145: Add "RPRED" mechanism for relocation predicates. (5% speedup for `ld.lld -O0`)

[Sean Silva via llvm-commits]

On Sat, Nov 26, 2016 at 11:49 PM, Noel Grandin <noelgrandin at gmail.com>
wrote:

> Once you're using power of two values I would expect the usual bit
> manipulation peephole optimizer to do the right thing, that's a pretty
> standard and simple optimization.
>

A peephole optimization can't get this, because such an optimization
doesn't have the information to figure out that only the values being
tested represent a closed universe identified by that bit.

You can see that the compiler doesn't fold this into a single bitwise test:
https://godbolt.org/g/ZIZrrE

The thing being done in this patch that the compiler fundamentally can't be
expected to do is to ignore the lower bits and only care about an
individual predicate bit; in order to do that you have to have some a
priori knowledge of how the bits are related. This patch can only do so
because the RelExpr values are chosen specifically so that this holds.

-- Sean Silva


> On Sun, 27 Nov 2016 at 09:47, Sean Silva via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> silvas added a comment.
>>
>> In https://reviews.llvm.org/D27145#606147, @grandinj wrote:
>>
>> > Do the use-sites need to be updated? Won't the compiler already
>> simplify such expressions (just concerned that the use-sites may be come
>> less legible)
>>
>>
>> The use sites are updated by this patch (search for the expressions that
>> look like `& RPRED_FOO`).
>>
>> The expressions that are being replaced are of the form `x == 7 || x == 9
>> || x == 35 || x == 12 || ...`. The best the compiler could do is infer
>> range information (based on the C language rules for enums) and make a
>> lookup table, but I'm not aware of any compiler that will currently do that
>> for this kind of expression.
>>
>> This patch is a type of data representation optimization that a compiler
>> can't be expected to do, even with whole-program analysis.
>>
>> The use sites might become less legible, but ideally we can hide each of
>> these operations behind a helper with a useful name, such as
>> refersToGotEntry, needsPlt, etc. so I don't expect it to matter much. I'm
>> not as much of an expert on relocations to come up with good names for each
>> of them, so some of them I have just left as a raw bit test. Hopefully
>> Rafael and others can help identify good names for these (and for the
>> `RPRED_*` enum values).
>>
>> > Also, for future source code readers, you may want a comment at the
>> definition site of the enum that it is a regular (exclusive) enum and not
>> some kind of flags/bit-field type thing.
>>
>> Once we settle down on the design, I'll need to do another pass through
>> the code and add some strategic comments.
>>
>>
>> https://reviews.llvm.org/D27145
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161127/4920f8c8/attachment.html>