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

Remove addrspaces from IR #7063

Closed
brson opened this issue Jun 11, 2013 · 10 comments
Closed

Remove addrspaces from IR #7063

brson opened this issue Jun 11, 2013 · 10 comments
Labels
A-codegen Area: Code generation E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@brson
Copy link
Contributor

brson commented Jun 11, 2013

addrspaces were part of our abandoned precise GC strategy. Now they just make the IR more complex.

@dotdash
Copy link
Contributor

dotdash commented Jun 12, 2013

If nobody objects, I'll try to work on this.

@dotdash
Copy link
Contributor

dotdash commented Jun 12, 2013

Looks like @graydon already has that done in 31ae4a1

@thestinger
Copy link
Contributor

@dotdash: we still output addrspace in the IR though.

@dotdash
Copy link
Contributor

dotdash commented Jun 12, 2013

Sorry, should have mentioned that that commit is only in @graydon's gc branch, which has not been merged, yet.

@nickdesaulniers
Copy link

This is blocking compiling llvm-bc to js through emscripten.

@graydon
Copy link
Contributor

graydon commented Jun 15, 2013

It's a self contained change, I'll try porting it over to master

bors added a commit that referenced this issue Jun 22, 2013
This is another big refactoring of `trans` though this is unlikely to have much of an
impact on code size or speed.

The major change here is the implementation of a `Type` struct which is the new
home for all your LLVM `TypeRef` needs. It's a simple wrapper struct, with static
methods for constructing types, then regular methods for
manipulating/interrogating them. The purpose of this is mostly to make the code
surrounding them somewhat more ideomatic. A line like: `T_ptr(T_ptr(T_i8()))` is 
now `Type::i8().ptr_to().ptr_to()`,which is much more like regular Rust code.

There are a variety of smaller changes here and there:

* Remove address spaces. At least it doesn't generate them, I haven't spent much
  time looking for related code.
* Use a macro for declaring the LLVM intrinsics, makes it look much nicer.
* Make the type for a string slice actually create a named `str_slice` type in LLVM,
  this makes reading the appropriate code much easier.
* Change the way struct and enum type names are generated. This just means
  that a struct like `struct Foo { a: int }` now produces the IR 
  `%struct.Foo = type { i64 }`, which is much easier to read. Similarly, other structs
  are a bit tighter to make it easier to read.

--- --- ---

This PR did get away from me a little, as I occasionally got distracted or as I fixed
up problems with unrelated code that were stopping me from continuing. One major
thing is that this PR contains the work from #7168, since that would have conflicted
with this and it was broken anyway. Sorry for bundling it like this.

Fixes #3670 and #7063

--- --- ---

EDIT: This no longer removes the llvm insn stats.
@nickdesaulniers
Copy link

What's the status of this bug?

@dotdash
Copy link
Contributor

dotdash commented Jun 25, 2013

Done, fix was in #7182

@dotdash
Copy link
Contributor

dotdash commented Jun 25, 2013

Do you have an example? It's working just fine for me, on its own as well as in combination with -S

@nickdesaulniers
Copy link

nvm something else is wrong with my environment

flip1995 pushed a commit to flip1995/rust that referenced this issue Apr 22, 2021
…arth

Fix false-positive `debug_assert` in `panic`

This fixes a false-positive in `clippy::panic` when `debug_assert` is used with a message.

Fixes rust-lang/rust-clippy#7062.

changelog: Fix false-positive in `panic` when `debug_assert` is used with a message
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-codegen Area: Code generation E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

5 participants