This is an archive of the discontinued LLVM Phabricator instance.

[NFC] Cleanup RangeMap.h
ClosedPublic

Authored by tberghammer on Feb 1 2016, 6:47 AM.

Details

Summary

[NFC] Cleanup RangeMap.h

The file contained very similar 4 implementation of the same data
structure with a lot of duplicated code and some minor API differences.
This CL refactor the class to eliminate the duplicated codes and to
unify the APIs.

RangeMap.h also contained a class called AddressDataArray what have very
little added functionality over an std::vector and used only by
ObjectFileMachO The CL moves the class to ObjectFileMachO.cpp as it isn't
belongs into RangeMap.h and shouldn't be used in new places anyway
because of the little added functionality.

Note1: As the change touches most of the line of RangeMap.h I run clang-format on the full file because we lose the history anyway.
Note2: I would prefer to get rid of AddressDataArray all together but I don't understand ObjectFileMachO well enough to make the change with high confidence

Diff Detail

Repository
rL LLVM

Event Timeline

tberghammer updated this revision to Diff 46531.Feb 1 2016, 6:47 AM
tberghammer retitled this revision from to [NFC] Cleanup RangeMap.h.
tberghammer updated this object.
tberghammer added reviewers: clayborg, labath.
tberghammer added a subscriber: lldb-commits.
clayborg accepted this revision.Feb 1 2016, 11:44 AM
clayborg edited edge metadata.

Looks fine. A few things I don't like, but I can live with:

  • Making constructors appear all on one line does save space, but it means you can't debug very well as stepping into these constructors will stop on the constructor line and then if you step, you will step over and out of the entire thing. Granted these classes are very simple and probably don't require debugging anymore, but it is a drawback to clang-format.
  • Many functions had variables that were put into temporaries like:
bool
DoesAdjoinOrIntersect (const Range &rhs) const
{
    const BaseType lhs_base = this->GetRangeBase();
    const BaseType rhs_base = rhs.GetRangeBase();
    const BaseType lhs_end = this->GetRangeEnd();
    const BaseType rhs_end = rhs.GetRangeEnd();
    bool result = (lhs_base <= rhs_end) && (lhs_end >= rhs_base);
    return result;
}

were reduced to lines like the following:

bool
DoesAdjoinOrIntersect(const Range &rhs) const
{
    return GetRangeBase() <= rhs.GetRangeEnd() && GetRangeEnd() >= rhs.GetRangeBase();
}

So I see the efficiency, but if I step into this function now it means less useful debugging as you will be stepping into and out of functions and you will lose the values and not be able to see what is going on. The compiler will get rid of the temporary variables when it optimizes things so I am not sure why these changes make things better.

This revision is now accepted and ready to land.Feb 1 2016, 11:44 AM

Looks fine. A few things I don't like, but I can live with:

  • Making constructors appear all on one line does save space, but it means you can't debug very well as stepping into these constructors will stop on the constructor line and then if you step, you will step over and out of the entire thing. Granted these classes are very simple and probably don't require debugging anymore, but it is a drawback to clang-format.

I think if this is not the format we want then we should check clang-format to support our use case. In this specific case I think putting everything in 1 line is fine as you see the function arguments when you step in and I also think clang-format will do something different for constructors with more code in them.

  • Many functions had variables that were put into temporaries like:
bool
DoesAdjoinOrIntersect (const Range &rhs) const
{
    const BaseType lhs_base = this->GetRangeBase();
    const BaseType rhs_base = rhs.GetRangeBase();
    const BaseType lhs_end = this->GetRangeEnd();
    const BaseType rhs_end = rhs.GetRangeEnd();
    bool result = (lhs_base <= rhs_end) && (lhs_end >= rhs_base);
    return result;
}

were reduced to lines like the following:

bool
DoesAdjoinOrIntersect(const Range &rhs) const
{
    return GetRangeBase() <= rhs.GetRangeEnd() && GetRangeEnd() >= rhs.GetRangeBase();
}

So I see the efficiency, but if I step into this function now it means less useful debugging as you will be stepping into and out of functions and you will lose the values and not be able to see what is going on. The compiler will get rid of the temporary variables when it optimizes things so I am not sure why these changes make things better.

I made these changes intentionally because I feel that inlining these temporaries improve the readability as you don't have to match the very similar 6-7 letter words by eye and it shouldn't hurt debugging too much because you can either evaluate the expression you are interested or just display "*this" or "rhs" as a frame variable. From efficiency perspective they won't matter if the types used are basic types (PODs) but if the compiler can optimize them out if they have a non-trivial constructor/destructor. I can revert those if you want.

No need to revert anything as these classes are stable now and don't need debugging. Just something to be aware of in other cases when you make future changes.

This revision was automatically updated to reflect the committed changes.
tfiala added a subscriber: tfiala.Feb 2 2016, 12:12 PM

This needs to be reverted. We've got 92 tests failing when this hit:

http://lab.llvm.org:8080/green/job/lldb_build_test/16222/

This needs to be reverted. We've got 92 tests failing when this hit:

http://lab.llvm.org:8080/green/job/lldb_build_test/16222/

I'm in the process of testing the issues go away with the revert. I'll commit the revert after that.

This needs to be reverted. We've got 92 tests failing when this hit:

http://lab.llvm.org:8080/green/job/lldb_build_test/16222/

I'm in the process of testing the issues go away with the revert. I'll commit the revert after that.

Reverted with r259556.