This is an archive of the discontinued LLVM Phabricator instance.

Implement the Waymarking as an independent utility
AbandonedPublic

Authored by ekatz on Oct 23 2019, 4:36 AM.

Details

Summary

This is an implementation that I am using for quite some time, for a personal project. Its need came from the requirement to use the algorithm for other purposes than the "Use" class.
I thought it could benefit others as well.
In any case, such a general algorithm deserves to be in the ADT library and not embedded into a specific usage. This way we also separate those logics from the Use class.

  • This is an improved version of the waymarking algorithm currently present - which combines the STOP flag with the Offset's digits. Further explanation available in the header file.

Diff Detail

Event Timeline

ekatz created this revision.Oct 23 2019, 4:36 AM
ekatz added a comment.Nov 4 2019, 10:44 AM

Yes. Not sure how do I do that.
Is it enough to change "llvm/docs/ProgrammersManual.rst"?

Yes. Not sure how do I do that.
Is it enough to change "llvm/docs/ProgrammersManual.rst"?

That should do it.

mehdi_amini added inline comments.
llvm/include/llvm/ADT/Waymarking.h
234

Can you improve the documentation of every public API in the file? If possible including usage example when appropriate. Thanks!

ekatz updated this revision to Diff 228958.Nov 12 2019, 2:11 PM
  • Improved documentation.
  • Fixed Programmer's Manual.
  • Added unit tests.
ekatz set the repository for this revision to rG LLVM Github Monorepo.Nov 19 2019, 5:17 AM

Improving the algorithm and separating the algorithm from Use should probably be two different patches.

Improving the algorithm and separating the algorithm from Use should probably be two different patches.

The improved algorithm is embedded in the solution of repurposing the waymarking algorithm into an independent utility. There is no middle stage, where I separate the old algorithm from Use.

foad added a reviewer: foad.Nov 20 2019, 5:49 AM
foad added a subscriber: foad.

I agree with @craig.topper that improving the algorithm and separating the algorithm from Use should be two different patches. Personally I am much more interested in the former than the latter.

Have you seen bug 6809 and read this thread: http://lists.llvm.org/pipermail/llvm-dev/2014-April/072326.html ?

Have you done any kind of profiling or measurement of your improved algorithm?

llvm/docs/ProgrammersManual.rst
3157

These diagrams are always confusing to read. I think it would be better to put numbers like -7 to the right of the vertical line instead of to the left; at the moment "-7" is underneath the binary encoding for 4, which is confusing. Also I think the vertical line for -14 is too far to the right.

ekatz marked an inline comment as done.Nov 20 2019, 8:34 AM
ekatz added inline comments.
llvm/docs/ProgrammersManual.rst
3157

I see what you mean. I'll change them, and fix -14.

ekatz added a comment.Nov 20 2019, 8:57 AM

I agree with @craig.topper that improving the algorithm and separating the algorithm from Use should be two different patches. Personally I am much more interested in the former than the latter.

Have you seen bug 6809 and read this thread: http://lists.llvm.org/pipermail/llvm-dev/2014-April/072326.html ?

Have you done any kind of profiling or measurement of your improved algorithm?

How do you and @craig.topper suggest I should separate it into 2 patches?
As I've explained, I can't separate the improvement of the algorithm from the one in the patch. I would have to re-design, re-write, re-test everything.
The only thing I can think of, is separate it into 2 patches: 1 for the utility, and 1 for changing Use, to use the utility. I can do that, but, correct me if I'm wrong, that is not what you suggested.

Regarding PR6809, I've seen it, and read everything regarding all the suggestions (including others) for improving the Waymarking algorithm.
I am not certain that my algorithm is better than the ones suggested (although it may be, or even about the same). What drove me into my improvement is just the dangling bit of the STOP tag, which could be used with the bits data, and not have to be alone (seemed like a waste).
Regarding the improvement of the number of bits used (for 64-bit), that was actually asked for a very long time, but in any case I wanted to generalize it (using templates) for any number of bits, and any location they may be in any type of data (not only pointer).

I do not think we get much (if any) REAL performance improvement (I tested), but only THEORETICAL improvement; but as explained above, this is not the reason for change. At least we don't get a slow down. ;)

The solution I propose is the one I am using on my personal project. I work with it for more than a year, now. Just thought to share it (plus - I added tests and updated the docs as needed).

foad added a comment.Nov 20 2019, 11:13 AM

How do you and @craig.topper suggest I should separate it into 2 patches?
As I've explained, I can't separate the improvement of the algorithm from the one in the patch. I would have to re-design, re-write, re-test everything.

Yes I am suggesting (not insisting) that you re-write and re-test the patch. Sorry if that seems like a lot of work, but I don't think it's unreasonable. As the contributing guide says: Independent changes should be submitted as separate patches as this makes reviewing easier.

The solution I propose is the one I am using on my personal project. I work with it for more than a year, now. Just thought to share it (plus - I added tests and updated the docs as needed).

I appreciate that.

ekatz added a comment.Nov 20 2019, 2:11 PM

I see why you suggest it, but what are the options available? Should I do this large change or drop it?
@lattner, may I have a second opinion? I know MLIR and SWIFT may benefit from it too, if they decide to use the utility.

ekatz abandoned this revision.Feb 11 2020, 7:56 AM

Separate into 2 different patches.

llvm/unittests/IR/UseTest.cpp