This is an archive of the discontinued LLVM Phabricator instance.

WIP alternative to r325686 (Implement name based structure type mapping).
AbandonedPublic

Authored by espindola on Feb 21 2018, 2:49 PM.

Details

Summary

The long term idea on how to improve the llvm type system is to have a single pointer type which makes the type graph a DAG.

Before that we need some heuristics as graph isomorphism has no known fast algorithm.

One of the heuristics we have is based on the name of the type. That is fairly unfortunate as the name should have no semantic meaning according to the spec. I think we should strive to not add more.

In r325686 another use of the name was added to handle the case when IRMover is given a non empty module and that module has multiple isomorphic types. That can happens as only the IRMover merges isomorphic types. The clang output, for example, can have duplicated types.

This patch changes the IRMover to merge isomorphic types on the destination module.

I now think that this should probably be made into an optimization pass that is run by clang. That way the types are merged before the file is written.

This patch still needs comments and to have the refactoring bits split out.

Diff Detail

Event Timeline

espindola created this revision.Feb 21 2018, 2:49 PM

Fix test failures.

evgeny777 added inline comments.Feb 22 2018, 7:13 AM
lib/Linker/IRMover.cpp
1459

You're mutating types while processing values in the module. This looks dangerous and actually triggers assertion when your patch is used to link real application (I can provide details and even test case, if you like). Can you do this in two steps instead:

  • create a list of objects you want to swap types for
  • process this list after TypeMap is fully filled.
espindola abandoned this revision.Feb 22 2018, 12:14 PM

I found a fundamental issue with this:

void ConstantExpr::destroyConstantImpl() {

getType()->getContext().pImpl->ExprConstants.remove(this);

}

Which means we cannot mutate the type without also rebuilding the constant uniquing tables.

I am out of ideas that are no really expensive like implementing a move constructor on Module and always starting the linker with an empty module.

I guess we really need to finish the changes for having a single pointer type.

I will LGTM the original change and ask for a second review on it in case someone has a better idea.