This is an archive of the discontinued LLVM Phabricator instance.

SymbolRewriter: introduce the SymbolRewriter pass
AbandonedPublic

Authored by abdulras on Mar 24 2014, 12:45 PM.

Details

Reviewers
grosbach
abdulras
Summary

To provide some additional context around this change. We (Facebook) have been using this for some internal testing and believe that this pass is generally useful and others may benefit from it. It provides a clean, flexible mechanism for symbol inter-positioning which is very useful in scenarios related to profiling. Furthermore, this pass may be directly useful in LLVM itself for the santizers which perform symbol inter-positioning for code analysis purposes. As such, we would like to merge this pass into the public LLVM repository.


This introduces the symbol rewriter. This is an IR->IR transformation that is
implemented as a CodeGenPrepare pass. This allows for the transparent
adjustment of the symbols during compilation.

It provides a clean, simple, elegant solution for symbol inter-positioning. This
technique is often used, such as in the various sanitizers and performance
analysis.

The control of this is via a custom YAML syntax map file that indicates source
to destination mapping, so as to avoid having the compiler to know the exact
details of the source to destination transformations.

Diff Detail

Event Timeline

abdulras updated this revision to Diff 11670.Jul 18 2014, 2:25 PM
abdulras retitled this revision from [PATCH] SymbolRewriter: introduce the SymbolRewriter pass to SymbolRewriter: introduce the SymbolRewriter pass.
grosbach requested changes to this revision.Jul 21 2014, 6:47 PM
grosbach edited edge metadata.

There are a lot of definitions that appear to be private to the rewriter in the include/llvm/.../.h file. I suspect most of that content can move to an anonymous namespace in the .cpp file.

In general, the code needs a lot more comments. It's generally clean code, which is great for understand how things work, but comments are still useful for the "why" of things.

A few inline comments as well. Once some of this is sorted out, I may have additional feedback, but this will give us a good starting place, I hope.

include/llvm/CodeGen/Passes.h
600 ↗(On Diff #11670)

Nothing calls the second version.

include/llvm/Transforms/Utils/SymbolRewriter.h
2

Needs file level comment header. Should include a fairly substantive description of what the pass does.

19

Why is there a SymbolRewriter namespace? The classes themselves should already provide the necessary scoping.

27

Comments on what these meen would be very helpful.

Why the RDT_ prefix? They're already namespaced inside the class.

53

const on a non-reference argument?

64

In general, these classes all need some comments explaining how they fit together.

lib/Transforms/Makefile
12 ↗(On Diff #11670)

Why is this in its own subdirectory? The header is in Utils (which seems to make sense), so the implementation should be, too, I'd think.

lib/Transforms/SymbolRewriter/SymbolRewriter.cpp
474 ↗(On Diff #11670)

Eh? Bitwise operator on the return values of empty()? That's a non-standard idiom. Rewriting in terms of boolean operators would make more sense.

495 ↗(On Diff #11670)

We have a "using namespace llvm" at the top. No need for the explicit scope operator here.

544 ↗(On Diff #11670)

Nothing calls this version of the factory function?

This revision now requires changes to proceed.Jul 21 2014, 6:47 PM

Given that the move will simplify the diff, I've addressed the inline comments and move into Utils from its own directory. I'll see about restructuring the descriptors to private from public. If clang ever needs to generate the descriptors, we can make them public then. Better to make as many of the types opaque as possible.

include/llvm/CodeGen/Passes.h
600 ↗(On Diff #11670)

Correct. Nothing calls it yet, the idea was to add this in this form to permit clang to read the file and provide the descriptor list to LLVM so that we do not have to read the file in the backend.

include/llvm/Transforms/Utils/SymbolRewriter.h
2

Added something to cover this. Happy to enhance it as necessary.

19

Well, this is being push up towards clang, but I don't see why it would need to be able to see the ModulePass subclass. I thought that the namespace was a good solution, but Im not tied to it. How would you prefer to handle this situation?

27

This was written way before we adopted C++11. I can use an enum class now. Comments added.

53

StringRefs shouldn't be const nor refs. Fixed.

64

Sure. Added a block comment describing them all. Let me know if you would like to enhance that in any way.

lib/Transforms/Makefile
12 ↗(On Diff #11670)

Thought it was something that was less of a general purpose utility for the other transformations. Happily moved as it greatly simplifies the build aspect.

lib/Transforms/SymbolRewriter/SymbolRewriter.cpp
474 ↗(On Diff #11670)

Sure. Done.

495 ↗(On Diff #11670)

Fixed.

544 ↗(On Diff #11670)

This is meant for the integration with clang. I figured that adding that up front would be better. Im happy to remove it for the time being.

abdulras updated this revision to Diff 15102.Oct 17 2014, 4:21 PM
abdulras edited edge metadata.

Address a number of Jim's comments.

abdulras updated this revision to Diff 15644.Oct 31 2014, 1:30 PM
abdulras edited edge metadata.

Address Jim's comments about reducing duplication and some error handling.

Looking much improved. A few questions, but in general I think this is fine.

include/llvm/IR/Module.h
373

This drops the const-ness of the return value. Do we need to do that?

include/llvm/Transforms/Utils/SymbolRewriter.h
50

Since the pass factory and the parser take parameters via reference, is there any need to have the actual classes for the descriptors and such in the public header file? Those seem like implementation details which can be in the .cpp file.

abdulras added inline comments.Nov 7 2014, 12:57 PM
include/llvm/IR/Module.h
373

Yes, in order to rename the Value.

include/llvm/Transforms/Utils/SymbolRewriter.h
50

Ah, I think I see what you mean, I can remove the concrete types from the header as only the iplist type information is needed.

abdulras accepted this revision.Nov 7 2014, 4:13 PM
abdulras added a reviewer: abdulras.

Committed in SVN r221548 with the recommended change.

abdulras abandoned this revision.Nov 12 2014, 11:35 AM

Seems that I can't close the revision :-(.