Skip to content
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

MIR: Do not require END_BLOCK to always exist #33030

Merged
merged 2 commits into from
Apr 21, 2016

Conversation

nagisa
Copy link
Member

@nagisa nagisa commented Apr 16, 2016

Basically, all this does, is removing restriction for END_BLOCK to exist past the first invocation of RemoveDeadBlocks pass. This way for functions whose CFG does not reach the END_BLOCK end up not containing the block.

As far as the implementation goes, I’m not entirely satisfied with the BasicBlock::end_block. I had hoped to make new a const fn and then just have a const END_BLOCK private to mir::build, but it turns out that constant functions don’t yet support conditionals nor a way to assert.

Once upon a time, along with START_BLOCK and END_BLOCK in the castle of important blocks also lived
a RESUME_BLOCK (or was it UNWIND_BLOCK? Either works, I don’t remember anymore). This trinity of
important blocks were required to always exist from the birth to death of the MIR-land they
belonged to.

Some time later, it was discovered that RESUME_BLOCK was just a lazy goon enjoying comfortable life
in the light of fame of the other two. Needless to say, once found out, the RESUME_BLOCK was
quickly slain and disposed of.

Now, the all-seeing eye of ours discovers that END_BLOCK is actually the more evil and better
disguised twin of the slain RESUME_BLOCK. Thus END_BLOCK gets slain and quickly disposed
of. Glory to the START_BLOCK, one and only lord of the important blocks’ castle!

---

Basically, all this does, is removing restriction for END_BLOCK to exist past the first invocation
of RemoveDeadBlocks pass. This way for functions whose CFG does not reach the `END_BLOCK` end up
not containing the block.

As far as the implementation goes, I’m not entirely satisfied with the `BasicBlock::end_block`, I
had hoped to make `new` a `const fn` and then just have a `const END_BLOCK` private to mir::build,
but it turns out that constant functions don’t yet support conditionals nor a way to assert.
@rust-highfive
Copy link
Collaborator

r? @arielb1

(rust_highfive has picked a reviewer for you, use r? to override)

@nagisa
Copy link
Member Author

nagisa commented Apr 16, 2016

r? @nikomatsakis

pub const fn end_block() -> BasicBlock {
BasicBlock(1)
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Why have this at all? Why not make it somehow local to the build package? Ideally, it'd just be a field of the Builder.

Copy link
Contributor

Choose a reason for hiding this comment

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

(Basically, I think we should go all the way and construct the END_BLOCK lazilly.)

@nagisa
Copy link
Member Author

nagisa commented Apr 19, 2016

Updated

@nikomatsakis
Copy link
Contributor

So I guess that this code will still build the return block, even for a function like fn foo() -> ! { panic!() }. I had sort of hoped to avoid that, but thinking a bit harder it seems sort of unavoidable. In any case I still like the lazy generation, since now it return/resume work analogously, which feels right.

@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Apr 20, 2016

📌 Commit d1180af has been approved by nikomatsakis

@bors
Copy link
Contributor

bors commented Apr 21, 2016

⌛ Testing commit d1180af with merge 6e03608...

bors added a commit that referenced this pull request Apr 21, 2016
MIR: Do not require END_BLOCK to always exist

Basically, all this does, is removing restriction for END_BLOCK to exist past the first invocation of RemoveDeadBlocks pass. This way for functions whose CFG does not reach the `END_BLOCK` end up not containing the block.

As far as the implementation goes, I’m not entirely satisfied with the `BasicBlock::end_block`. I had hoped to make `new` a `const fn` and then just have a `const END_BLOCK` private to mir::build, but it turns out that constant functions don’t yet support conditionals nor a way to assert.
@bors
Copy link
Contributor

bors commented Apr 21, 2016

💔 Test failed - auto-win-msvc-32-opt

@alexcrichton
Copy link
Member

@bors: retry

On Wed, Apr 20, 2016 at 11:36 PM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-win-msvc-32-opt
http://buildbot.rust-lang.org/builders/auto-win-msvc-32-opt/builds/3083


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#33030 (comment)

@bors bors merged commit d1180af into rust-lang:master Apr 21, 2016
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.

6 participants