Skip to content

Bounds context [1/n] #807

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 15 commits into from
Apr 2, 2020
Merged

Bounds context [1/n] #807

merged 15 commits into from
Apr 2, 2020

Conversation

kkjeer
Copy link
Contributor

@kkjeer kkjeer commented Mar 9, 2020

This PR adds a bounds context member to the CheckingState class and determines the incoming (declared) bounds context for a statement. After #802 is merged, the bounds context can be updated during bounds checking.

Testing:

  • Added bounds-context.c to test dumping the bounds context.
  • Passed manual testing on Windows.
  • Automated testing in progress.

@kkjeer kkjeer requested review from dtarditi and mgrang March 9, 2020 18:59
OrderedDecls.push_back(Pair.first);
llvm::sort(OrderedDecls.begin(), OrderedDecls.end(),
[] (DeclaratorDecl *A, DeclaratorDecl *B) {
if (A->getNameAsString() == B->getNameAsString())
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could write this comparator more succinctly as:
return std::tie(A->getNameAsString(), A->getLocation()) < std::tie(B->getNameAsString(), B->getLocation())

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After I made this change, there were build warnings related to A->getNameAsString(), etc. not being lvalues so I've reverted it at least for now.

Copy link
Member

@dtarditi dtarditi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, looks good. I had one minor code suggestion.

Could you add comments explaining the general approach that is being used? As we discussed off-line, the goal of attaching contexts and propagating them around is that we can determine what variables with bounds declarations are in scope? Also, what is the effect on compile time of this change?

@@ -2867,7 +2958,10 @@ namespace {
BoundsExpr *B = nullptr;
InteropTypeExpr *IT = nullptr;
if (VD) {
B = VD->getBoundsExpr();
if (State.UC[VD])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should use the find method instead of the subscript operator? This avoids two lookups in the DenseMap.

@@ -2958,8 +2961,9 @@ namespace {
BoundsExpr *B = nullptr;
InteropTypeExpr *IT = nullptr;
if (VD) {
if (State.UC[VD])
B = State.UC[VD];
auto Declared = State.UC.find(VD);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would do it this way:

if (State.UC.count(VD))
  B = State.UC[VD];

@kkjeer
Copy link
Contributor Author

kkjeer commented Mar 17, 2020

Overall, looks good. I had one minor code suggestion.

Could you add comments explaining the general approach that is being used? As we discussed off-line, the goal of attaching contexts and propagating them around is that we can determine what variables with bounds declarations are in scope? Also, what is the effect on compile time of this change?

This change resulted in the following compile time deltas compared to the current master:

  • Debug X64 Windows: 1.5% decrease in compile time
  • Debug X86 Windows: 11% increase in compile time
  • Debug X64 Linux: 1.7% decrease in compile time

Copy link
Member

@dtarditi dtarditi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants