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

Sean Silva via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Nov 26 23:47:07 PST 2016


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





More information about the llvm-commits mailing list