Skip to content

Vacation gardening #5920

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 6 commits into from
Nov 25, 2016
Merged

Vacation gardening #5920

merged 6 commits into from
Nov 25, 2016

Conversation

gottesmm
Copy link
Contributor

This PR contains a few different gardening changes. The main meat of the change is:

  1. SILArguments are always created via SILBasicBlock::* methods instead of via inline placement new.
  2. SILBasicBlocks are always created via SILFunction::* methods instead of via inline placement new.

This makes the API of SILArgument, SILBasicBlock follow the already enforced contract that a SILBasicBlock can only be created given its parent SILFunction and a SILArgument can only be created given its parent block.

As an additional benefit, it makes looking at memory allocations related to SILArguments and SILBasicBlocks significantly easier since when compiling without LTO all SILArguments/SILBasicBlocks are guaranteed to be allocated in the same call frame. This implies one only needs to perform a simple invert call tree in instruments to find all of such allocations.

…Block.

This eliminates all inline creation of SILBasicBlock via placement new.

There are a few reasons to do this:

1. A SILBasicBlock is always created with a parent function. This commit
formalizes this into the SILBasicBlock API by only allowing for SILFunctions to
create SILBasicBlocks. This is implemented via the type system by making all
SILBasicBlock constructors private. Since SILFunction is a friend of
SILBasicBlock, SILFunction can still create a SILBasicBlock without issue.

2. Since all SILBasicBlocks will be created in only a few functions, it becomes
very easy to determine using instruments the amount of memory being allocated
for SILBasicBlocks by simply inverting the call tree in Allocations.

With LTO+PGO, normal inlining can occur if profitable so there shouldn't be
overhead that we care about in shipping compilers.
Before this commit all code relating to handling arguments in SILBasicBlock had
somewhere in the name BB. This is redundant given that the class's name is
already SILBasicBlock. This commit drops those names.

Some examples:

getBBArg() => getArgument()
BBArgList => ArgumentList
bbarg_begin() => args_begin()
…nt list manipulation section.

I am not sure why it was put here originally, but I believe it is still there
due to bitrot.
…eArgument instead of inline placement new.

The reasoning here is the same as in e42bf07.
@gottesmm
Copy link
Contributor Author

@swift-ci Please test and merge

@gottesmm
Copy link
Contributor Author

Linux failed b/c I needed to update lldb

@gottesmm
Copy link
Contributor Author

swift-lldb/#82

@swift-ci Please test Linux platform

@gottesmm
Copy link
Contributor Author

swift-lldb#82

@swift-ci Please test linux platform

@gottesmm
Copy link
Contributor Author

apple/swift-lldb#82

@swift-ci Please test linux platform

@swift-ci
Copy link
Contributor

Build failed
Jenkins build - Swift Test Linux Platform
Git Commit - 0a8c54d
Test requested by - @gottesmm

@gottesmm
Copy link
Contributor Author

Linux full test build is broken. I am going to try the smoke test...

@gottesmm
Copy link
Contributor Author

apple/swift-lldb#82

@swift-ci Please smoke test linux platform

@gottesmm gottesmm merged commit 96837ba into swiftlang:master Nov 25, 2016
@gottesmm gottesmm deleted the vacation_gardening branch November 25, 2016 15:17
jjgod added a commit to jjgod/swift that referenced this pull request Nov 25, 2016
[448/1413] Building CXX object lib/SILOptimizer/CMakeFiles/swiftSILOptimizer.dir/IPO/ClosureSpecializer.cpp.o
/Volumes/Home/swift-source/swift/lib/SILOptimizer/IPO/ClosureSpecializer.cpp:569:14: warning: unused variable 'M' [-Wunused-variable]
  SILModule &M = Cloned->getModule();
             ^
1 warning generated.

Introduced by swiftlang#5920.
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.

2 participants