llvm-canon

[mpaszkowski]

Summary

Added a new llvm-canon tool which aims to transform LLVM Modules into a canonical form by reordering and renaming instructions while preserving the same semantics. This tool makes it easier to spot semantic differences while diffing two modules which have undergone different transformation passes.

[fdeazeve]

tools/llvm-canon/canonicalizer.cpp

235 ↗

(On Diff #214431)

Isn't this a reference to a pointer? I think you meant auto *OP. The reason I'm saying this is because you use dyn_cast below, and yet dyn_cast doesn't work with references.

298 ↗

(On Diff #214431)

Guidelines suggest using auto * when copying pointers. https://llvm.org/docs/CodingStandards.html#beware-unnecessary-copies-with-auto

329 ↗

(On Diff #214431)

typo: flag

[alexandre.isoard]

Seems like a great idea!

Could we have an option to only rename without reordering? I have found, in the past, some issue that were order sensitive, but rarely name sensitive, and it would be great to be able to debug those.
Also, in my personal implementation I had missed anonymous types and anonymous global variable, I don't know if we captured those here.

Note that I'm not sure if we can name all metadata or function attribute lists.

[mpaszkowski]

First of all, thank you for your valuable feedback!

In D66029#1623654, @lebedev.ri wrote:

Please run clang-format on the patch.
What is the plan for tests here?

Sure, will run clang-format!

When it comes to tests, I don't have any plan yet. I am not sure if testing every scenario is the best solution here - the canonicalization techniques may change easily as these are my 'best' approaches.
Can you think of any way how to test it sensibly?

In D66029#1623760, @hfinkel wrote:

I also recommend that you canonicalize PHI nodes. In past experiments looking for fixed points in the optimization pipeline, this came up as a significant issue. The order of the predecessors in the PHI operand lists don't carry any significance, also also sometimes a predecessor can be listed multiple times (always with the same corresponding value). It's probably best to canonicalize those so each predecessor is listed only once and the blocks appear in their natural order.

At a high level, I'd much rather see the underlying logic under lib/Transforms/Utils, and then we can just run this with opt and we don't need a separate utility.

I will take a look at PHI nodes and move the pass to Transforms.

In D66029#1626100, @alexandre.isoard wrote:

Seems like a great idea!

Could we have an option to only rename without reordering? I have found, in the past, some issue that were order sensitive, but rarely name sensitive, and it would be great to be able to debug those.
Also, in my personal implementation I had missed anonymous types and anonymous global variable, I don't know if we captured those here.

Note that I'm not sure if we can name all metadata or function attribute lists.

I will add the option to run just naming or reordering - both stages are independent. We also haven't considered anonymous types and anonymous global variables.

[mpaszkowski]

I would like to thank everyone for your valuable feedback! I have fixed the code and moved the pass to lib/Tranfroms/Utils. I hope I have correctly integrated the pass with the rest of the LLVM (we should have some checklist for that).

[mpaszkowski]

tools/llvm-canon/canonicalizer.cpp

88 ↗

(On Diff #214431)

You are right, this number cannot be generated by srand. We want the canonicalization to be deterministic.

[mpaszkowski]

• PHI node canonicalization
• Tests
• Release notes
• Docs

[mpaszkowski]

We have been experimenting with various ways of reordering output instructions hoping to add it now, but it looks to be much tougher than we thought. We hope to add it in a next commit.

@hfinkel
Now the canonicalizer sorts values in PHI nodes. After a discussion, I have decided not to remove duplicates. Those duplicates could come from some other passes and in my opinion, the canonicalizer should make them stand out instead of removing them.
Values are sorted alphabetically according to canonicalized names of corresponding basic blocks.

I am open to suggestions. I would like to ask for a final review of the updated diff. Especially I would like to know if I have integrated the pass with the rest of the LLVM correctly.

[hfinkel]

Now the canonicalizer sorts values in PHI nodes. After a discussion, I have decided not to remove duplicates. Those duplicates could come from some other passes and in my opinion, the canonicalizer should make them stand out instead of removing them.

I suppose that you mean that, if passes are introducing duplicates, that's something that we'd rather fix? That might be true. I'm okay with proceeding on this basis. If we need the deduplicating behavior we'll find out.

[mpaszkowski]

In D66029#1639228, @hfinkel wrote:

Now the canonicalizer sorts values in PHI nodes. After a discussion, I have decided not to remove duplicates. Those duplicates could come from some other passes and in my opinion, the canonicalizer should make them stand out instead of removing them.

I suppose that you mean that, if passes are introducing duplicates, that's something that we'd rather fix? That might be true. I'm okay with proceeding on this basis. If we need the deduplicating behavior we'll find out.

Yes, this is exactly what I meant . We will see how this works, as you said alternatively we can add that later.

Does the rest of the code look good to you? I will need someone to commit this patch for me (I don't have commit rights).

[plotfi]

Looking a lot better.

[mpaszkowski]

Gentle ping ;)

I would like to ask someone to commit this for me. I don't have commit rights.

[lebedev.ri]

Some initial comments.
In general:

• Don't spell out type if you just used *cast<???>
• Don't drop */& after auto
• Do end files with newline
• Consider small-size optimization. Please try to see if some of these std::string can be replaced with reasonably-sized llvm::SmallString<?>
• Please consider preallocating some strings
• This needs a bit more refactoring i think

docs/Passes.rst

693 ↗

(On Diff #216009)

Too many -

include/llvm/Transforms/Utils/IRCanonicalizer.h

96 ↗

(On Diff #216009)

Please make sure that files end with newlines

lib/Transforms/Utils/IRCanonicalizer.cpp

37–45 ↗

(On Diff #216009)

Should these have defaults?

57–78 ↗

(On Diff #216009)

runOnFunction() ?

73 ↗

(On Diff #216009)

if(auto *PN = dyn_cast<PHINode>(&I))

150–170 ↗

(On Diff #216009)

This block will result in most of memory nagging in this pass.

151 ↗

(On Diff #216009)

Can you make any reasonable guess as to what would be 90'th percentile of Operand string length?
Maybe try using SmallString<64>.

166 ↗

(On Diff #216009)

It would be really good to predict+preallocate the size here.

183 ↗

(On Diff #216009)

const int& output = ?
The type is not clear to me here.

190 ↗

(On Diff #216009)

auto* CI

219 ↗

(On Diff #216009)

Same comments as for the previous function

263 ↗

(On Diff #216009)

auto* IOP

270 ↗

(On Diff #216009)

const int Code = ?

277 ↗

(On Diff #216009)

const auto *CI

305 ↗

(On Diff #216009)

auto*

306 ↗

(On Diff #216009)

auto*

331–335 ↗

(On Diff #216009)

I'm sensing a repetitive pattern. I think you want to refactor it.

388 ↗

(On Diff #216009)

auto*

427–430 ↗

(On Diff #216009)

llvm::less_first

504 ↗

(On Diff #216009)

!I->user_empty() ?

[plotfi]

In D66029#1648887, @mpaszkowski wrote:

Gentle ping ;)

I would like to ask someone to commit this for me. I don't have commit rights.

I don't know the current process but I think you should ask for them and commit it yourself so that you get the credit (and the blame :-P ) for this work.

PL

[mpaszkowski]

lib/Transforms/Utils/IRCanonicalizer.cpp

37–45 ↗

(On Diff #216009)

They are all false by default, this is why I haven't explicitly stated their value. I don't think this will change in the future.

57–78 ↗

(On Diff #216009)

Yes! I don't know why I haven't changed this any earlier.

166 ↗

(On Diff #216009)

Changed to standard for-loop and moved to the end of the function.

331–335 ↗

(On Diff #216009)

The pattern only repeats for creating the operand list.

[mpaszkowski]

Updated the diff for the new revision, refactored naming functions, accepted suggestions by lebedev.
Thank you for the review! @lebedev.ri
Is the code ready for the mainline?

[aykevl]

Just a drive by comment from someone interested in this pass.

docs/Passes.rst

697 ↗

(On Diff #222320)

It looks like this sentence is not finished.

[mpaszkowski]

Thanks, will fix that!

[mpaszkowski]

First of all, I am sorry for such a late reply (had many things going on recently). I have updated the patch for the upstream version of the LLVM. Thanks to @aykevl I have corrected the docs/Passes.rst file. Additionaly, I have added a new flag which enables/disables sorting and reordering operands in commutative instructions.

In the meantime, the project has been presented at the LLVM Developers' Meeting 2019 in San Jose. You may want to check out the slides or watch the presentation.

I would like to thank everyone who came to the presentation for all the valuable feedback and support! It was really nice to see you all.

Hopefully, the code looks good now. I would like to ask for further comments and eventual LGTM so the code can be committed to the mainline.

[mpaszkowski]

Gentle ping! Is the code ready for the mainline?
Could you @plotfi take a look?

[plotfi]

I've got a few nits. Will do a second pass shortly.

llvm/lib/Transforms/Utils/IRCanonicalizer.cpp

176

get this to conform to llvm style (ie OutputFootprint)

179

Output as well.

235

nit: auto *IOP

327

nit: HasCanonicalName

371

not: auto *IOP

422

not: auto *VOP

440

nit: Position

462

nit: LHS and RHS

518

for (const auto &OP : I->operands())
  if (isa<Instruction>(OP))
    return false; // Found non-immediate operand (instruction).

549

unsigned Count = 0;
for (const auto &B : *Func) {
  for (const auto &E : B) {
    if (&E == I)
      Outputs.insert(Count);
    Count++;
  }
}

563

nit: auto *U and auto *UI

[plotfi]

Please update the diff so the new HarborMaster setup can run some tests on it :-)

[plotfi]

llvm/include/llvm/Transforms/Utils/IRCanonicalizer.h

1 ↗

(On Diff #257243)

Does this need to be a separate header? Can the class be contained in a anonymous namespace in the .cpp file (IRCanonicalizer.cpp) like some of the other passes?

61 ↗

(On Diff #257243)

Is there any significance of this magic number? Can you either set this by a cl::opt or generated at runtime (maybe something using srand (time(NULL))) ?

[plotfi]

Ping? Any Update on this? I think this is close to an LGTM.

[mpaszkowski]

Thank you @plotfi for review! I will update the diff in a second.

llvm/include/llvm/Transforms/Utils/IRCanonicalizer.h

61 ↗

(On Diff #257243)

There is no significance in this particular number but it needs to be consistent among all canonicalized modules (so this shouldn't be set by cl::opt or randomly generated). I have used particularly this number since it has been used in many other places in LLVM, for example here.

[mpaszkowski]

Updated the diff with suggestions from @plotfi.

[mpaszkowski]

How do we get HarborMaster to run tests on the patch?

[plotfi]

In D66029#2016444, @mpaszkowski wrote:

How do we get HarborMaster to run tests on the patch?

I thought it just does it. Strange. Maybe because this is an older diff?

[plotfi]

llvm/test/Transforms/IRCanonicalizer/reordering-instructions.ll

6

consider making the last 3 check lines "CHECK-NEXT"

tools/llvm-canon/canonicalizer.cpp

88 ↗

(On Diff #214431)

Ah yes, that makes a lot of sense. The MIR Canonicalizer ran into the same sort of issue. That's why the value-numbering-esque rewrite of it doesn't hash certain types of MachineOperands that might be different run to run.

[plotfi]

Nice work. I think this LGTM.

[mpaszkowski]

In D66029#2028455, @plotfi wrote:

Nice work. I think this LGTM.

Thank you @plotfi ! I will update one of the tests and request commit access :)

[mpaszkowski]

Reverted the commit and reopened the review after unsuccessful builds:

1. builder clang-cmake-x86_64-sde-avx512-linux while building llvm
2. clang-armv7-linux-build-cache while building llvm
3. clang-aarch64-linux-build-cache while building llvm
4. clang-cmake-x86_64-avx2-linux while building cfe

[mpaszkowski]

@plotfi Should I create a new review so that the HarborMaster will be able run the builds after the fix?

[plotfi]

In D66029#2052030, @mpaszkowski wrote:

@plotfi Should I create a new review so that the HarborMaster will be able run the builds after the fix?

If updating this review did not trigger it, go ahead and create a new one. Sorry for the late reply @mpaszkowski.

[plotfi]

@mpaszkowski ping

[mpaszkowski]

In D66029#2255874, @plotfi wrote:

@mpaszkowski ping

Sorry, I will update the review and commit again at the end of next week.

[mpaszkowski]

Updated the patch to for the new version of LLVM. Currently the pass still utilizes the legacy pass manager. The pass will be ported to the new pass manager in a separate review.