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

[Noel Grandin via llvm-commits]

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.
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/165829fe/attachment.html>