2014-10-14 13:41:50 -05:00
|
|
|
// Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT
|
2012-12-03 18:48:01 -06:00
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2014-03-21 20:05:05 -05:00
|
|
|
#![allow(non_camel_case_types)]
|
2013-05-17 17:28:44 -05:00
|
|
|
|
2014-11-14 16:20:57 -06:00
|
|
|
use std::cell::{RefCell, Cell};
|
2014-08-27 20:46:52 -05:00
|
|
|
use std::collections::HashMap;
|
2015-01-20 17:45:07 -06:00
|
|
|
use std::fmt::Debug;
|
2015-02-17 22:48:07 -06:00
|
|
|
use std::hash::Hash;
|
2014-12-10 21:46:38 -06:00
|
|
|
use std::iter::repeat;
|
2014-11-10 14:27:56 -06:00
|
|
|
use std::time::Duration;
|
std: Stabilize the std::hash module
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
2014-12-09 14:37:23 -06:00
|
|
|
use std::collections::hash_state::HashState;
|
2014-11-10 14:27:56 -06:00
|
|
|
|
2012-09-04 13:54:36 -05:00
|
|
|
use syntax::ast;
|
2013-08-14 08:54:35 -05:00
|
|
|
use syntax::visit;
|
|
|
|
use syntax::visit::Visitor;
|
2012-12-23 16:41:37 -06:00
|
|
|
|
2015-01-10 10:54:15 -06:00
|
|
|
// The name of the associated type for `Fn` return types
|
|
|
|
pub const FN_OUTPUT_NAME: &'static str = "Output";
|
|
|
|
|
2014-11-07 15:26:26 -06:00
|
|
|
// Useful type to use with `Result<>` indicate that an error has already
|
|
|
|
// been reported to the user, so no need to continue checking.
|
2015-01-28 07:34:18 -06:00
|
|
|
#[derive(Clone, Copy, Debug)]
|
2014-11-08 05:59:10 -06:00
|
|
|
pub struct ErrorReported;
|
|
|
|
|
2014-12-08 19:26:43 -06:00
|
|
|
pub fn time<T, U, F>(do_it: bool, what: &str, u: U, f: F) -> T where
|
|
|
|
F: FnOnce(U) -> T,
|
|
|
|
{
|
2014-11-14 16:20:57 -06:00
|
|
|
thread_local!(static DEPTH: Cell<uint> = Cell::new(0));
|
2013-09-27 21:46:09 -05:00
|
|
|
if !do_it { return f(u); }
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-03 01:19:29 -06:00
|
|
|
|
2014-11-14 16:20:57 -06:00
|
|
|
let old = DEPTH.with(|slot| {
|
|
|
|
let r = slot.get();
|
|
|
|
slot.set(r + 1);
|
|
|
|
r
|
|
|
|
});
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-03 01:19:29 -06:00
|
|
|
|
2014-11-10 14:27:56 -06:00
|
|
|
let mut u = Some(u);
|
|
|
|
let mut rv = None;
|
2014-12-08 19:26:43 -06:00
|
|
|
let dur = {
|
|
|
|
let ref mut rvp = rv;
|
|
|
|
|
|
|
|
Duration::span(move || {
|
|
|
|
*rvp = Some(f(u.take().unwrap()))
|
|
|
|
})
|
|
|
|
};
|
2014-11-10 14:27:56 -06:00
|
|
|
let rv = rv.unwrap();
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-03 01:19:29 -06:00
|
|
|
|
2014-12-10 21:46:38 -06:00
|
|
|
println!("{}time: {}.{:03} \t{}", repeat(" ").take(old).collect::<String>(),
|
2014-11-13 10:48:38 -06:00
|
|
|
dur.num_seconds(), dur.num_milliseconds() % 1000, what);
|
2014-11-14 16:20:57 -06:00
|
|
|
DEPTH.with(|slot| slot.set(old));
|
Implement LTO
This commit implements LTO for rust leveraging LLVM's passes. What this means
is:
* When compiling an rlib, in addition to insdering foo.o into the archive, also
insert foo.bc (the LLVM bytecode) of the optimized module.
* When the compiler detects the -Z lto option, it will attempt to perform LTO on
a staticlib or binary output. The compiler will emit an error if a dylib or
rlib output is being generated.
* The actual act of performing LTO is as follows:
1. Force all upstream libraries to have an rlib version available.
2. Load the bytecode of each upstream library from the rlib.
3. Link all this bytecode into the current LLVM module (just using llvm
apis)
4. Run an internalization pass which internalizes all symbols except those
found reachable for the local crate of compilation.
5. Run the LLVM LTO pass manager over this entire module
6a. If assembling an archive, then add all upstream rlibs into the output
archive. This ignores all of the object/bitcode/metadata files rust
generated and placed inside the rlibs.
6b. If linking a binary, create copies of all upstream rlibs, remove the
rust-generated object-file, and then link everything as usual.
As I have explained in #10741, this process is excruciatingly slow, so this is
*not* turned on by default, and it is also why I have decided to hide it behind
a -Z flag for now. The good news is that the binary sizes are about as small as
they can be as a result of LTO, so it's definitely working.
Closes #10741
Closes #10740
2013-12-03 01:19:29 -06:00
|
|
|
|
2013-03-21 04:50:02 -05:00
|
|
|
rv
|
|
|
|
}
|
2011-06-15 13:19:50 -05:00
|
|
|
|
2014-12-08 19:26:43 -06:00
|
|
|
pub fn indent<R, F>(op: F) -> R where
|
2015-01-20 17:45:07 -06:00
|
|
|
R: Debug,
|
2014-12-08 19:26:43 -06:00
|
|
|
F: FnOnce() -> R,
|
|
|
|
{
|
2012-04-05 22:59:07 -05:00
|
|
|
// Use in conjunction with the log post-processor like `src/etc/indenter`
|
|
|
|
// to make debug output more readable.
|
2013-10-21 15:08:31 -05:00
|
|
|
debug!(">>");
|
2012-10-23 13:28:20 -05:00
|
|
|
let r = op();
|
2014-12-20 02:09:35 -06:00
|
|
|
debug!("<< (Result = {:?})", r);
|
2013-02-15 03:14:34 -06:00
|
|
|
r
|
2012-04-05 22:59:07 -05:00
|
|
|
}
|
|
|
|
|
2014-06-06 08:51:42 -05:00
|
|
|
pub struct Indenter {
|
|
|
|
_cannot_construct_outside_of_this_module: ()
|
2013-02-27 18:13:53 -06:00
|
|
|
}
|
|
|
|
|
2014-06-06 08:51:42 -05:00
|
|
|
impl Drop for Indenter {
|
2013-10-21 15:08:31 -05:00
|
|
|
fn drop(&mut self) { debug!("<<"); }
|
2012-04-05 22:59:07 -05:00
|
|
|
}
|
|
|
|
|
2014-06-06 08:51:42 -05:00
|
|
|
pub fn indenter() -> Indenter {
|
2013-10-21 15:08:31 -05:00
|
|
|
debug!(">>");
|
2014-06-06 08:51:42 -05:00
|
|
|
Indenter { _cannot_construct_outside_of_this_module: () }
|
2012-04-05 22:59:07 -05:00
|
|
|
}
|
|
|
|
|
2014-12-08 19:26:43 -06:00
|
|
|
struct LoopQueryVisitor<P> where P: FnMut(&ast::Expr_) -> bool {
|
|
|
|
p: P,
|
2013-09-25 03:55:04 -05:00
|
|
|
flag: bool,
|
2013-08-14 08:54:35 -05:00
|
|
|
}
|
|
|
|
|
2014-12-08 19:26:43 -06:00
|
|
|
impl<'v, P> Visitor<'v> for LoopQueryVisitor<P> where P: FnMut(&ast::Expr_) -> bool {
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_expr(&mut self, e: &ast::Expr) {
|
2013-09-25 03:55:04 -05:00
|
|
|
self.flag |= (self.p)(&e.node);
|
2012-08-06 14:34:08 -05:00
|
|
|
match e.node {
|
2012-06-20 20:50:44 -05:00
|
|
|
// Skip inner loops, since a break in the inner loop isn't a
|
|
|
|
// break inside the outer loop
|
2015-01-22 17:59:00 -06:00
|
|
|
ast::ExprLoop(..) | ast::ExprWhile(..) => {}
|
2014-09-12 05:10:30 -05:00
|
|
|
_ => visit::walk_expr(self, e)
|
2012-06-20 20:50:44 -05:00
|
|
|
}
|
2013-08-14 08:54:35 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Takes a predicate p, returns true iff p is true for any subexpressions
|
|
|
|
// of b -- skipping any inner loops (loop, while, loop_body)
|
2014-12-08 19:26:43 -06:00
|
|
|
pub fn loop_query<P>(b: &ast::Block, p: P) -> bool where P: FnMut(&ast::Expr_) -> bool {
|
2013-08-29 20:04:17 -05:00
|
|
|
let mut v = LoopQueryVisitor {
|
|
|
|
p: p,
|
2013-09-25 03:55:04 -05:00
|
|
|
flag: false,
|
2013-08-29 20:04:17 -05:00
|
|
|
};
|
2014-09-12 05:10:30 -05:00
|
|
|
visit::walk_block(&mut v, b);
|
2013-09-25 03:55:04 -05:00
|
|
|
return v.flag;
|
2012-06-14 14:24:56 -05:00
|
|
|
}
|
|
|
|
|
2014-12-08 19:26:43 -06:00
|
|
|
struct BlockQueryVisitor<P> where P: FnMut(&ast::Expr) -> bool {
|
|
|
|
p: P,
|
2013-09-25 03:55:04 -05:00
|
|
|
flag: bool,
|
2013-08-14 08:54:35 -05:00
|
|
|
}
|
|
|
|
|
2014-12-08 19:26:43 -06:00
|
|
|
impl<'v, P> Visitor<'v> for BlockQueryVisitor<P> where P: FnMut(&ast::Expr) -> bool {
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_expr(&mut self, e: &ast::Expr) {
|
2013-09-25 03:55:04 -05:00
|
|
|
self.flag |= (self.p)(e);
|
2014-09-12 05:10:30 -05:00
|
|
|
visit::walk_expr(self, e)
|
2013-08-14 08:54:35 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-10-18 14:20:18 -05:00
|
|
|
// Takes a predicate p, returns true iff p is true for any subexpressions
|
|
|
|
// of b -- skipping any inner loops (loop, while, loop_body)
|
2014-12-08 19:26:43 -06:00
|
|
|
pub fn block_query<P>(b: &ast::Block, p: P) -> bool where P: FnMut(&ast::Expr) -> bool {
|
2013-08-29 20:04:17 -05:00
|
|
|
let mut v = BlockQueryVisitor {
|
|
|
|
p: p,
|
2013-09-25 03:55:04 -05:00
|
|
|
flag: false,
|
2013-08-29 20:04:17 -05:00
|
|
|
};
|
2014-09-12 05:10:30 -05:00
|
|
|
visit::walk_block(&mut v, &*b);
|
2013-09-25 03:55:04 -05:00
|
|
|
return v.flag;
|
2012-03-10 22:34:57 -06:00
|
|
|
}
|
2014-08-27 20:46:52 -05:00
|
|
|
|
2014-11-25 20:17:11 -06:00
|
|
|
/// K: Eq + Hash<S>, V, S, H: Hasher<S>
|
|
|
|
///
|
2015-02-19 20:35:52 -06:00
|
|
|
/// Determines whether there exists a path from `source` to `destination`. The
|
|
|
|
/// graph is defined by the `edges_map`, which maps from a node `S` to a list of
|
|
|
|
/// its adjacent nodes `T`.
|
2014-11-25 20:17:11 -06:00
|
|
|
///
|
2015-02-19 20:35:52 -06:00
|
|
|
/// Efficiency note: This is implemented in an inefficient way because it is
|
|
|
|
/// typically invoked on very small graphs. If the graphs become larger, a more
|
|
|
|
/// efficient graph representation and algorithm would probably be advised.
|
2015-02-17 22:48:07 -06:00
|
|
|
pub fn can_reach<T, S>(edges_map: &HashMap<T, Vec<T>, S>, source: T,
|
|
|
|
destination: T) -> bool
|
|
|
|
where S: HashState, T: Hash + Eq + Clone,
|
2014-08-27 20:46:52 -05:00
|
|
|
{
|
|
|
|
if source == destination {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Do a little breadth-first-search here. The `queue` list
|
|
|
|
// doubles as a way to detect if we've seen a particular FR
|
|
|
|
// before. Note that we expect this graph to be an *extremely
|
|
|
|
// shallow* tree.
|
|
|
|
let mut queue = vec!(source);
|
|
|
|
let mut i = 0;
|
|
|
|
while i < queue.len() {
|
2014-11-06 11:25:16 -06:00
|
|
|
match edges_map.get(&queue[i]) {
|
2014-08-27 20:46:52 -05:00
|
|
|
Some(edges) => {
|
2015-01-31 11:20:46 -06:00
|
|
|
for target in edges {
|
2014-08-27 20:46:52 -05:00
|
|
|
if *target == destination {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if !queue.iter().any(|x| x == target) {
|
|
|
|
queue.push((*target).clone());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
None => {}
|
|
|
|
}
|
|
|
|
i += 1;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
2014-10-14 13:41:50 -05:00
|
|
|
|
|
|
|
/// Memoizes a one-argument closure using the given RefCell containing
|
|
|
|
/// a type implementing MutableMap to serve as a cache.
|
|
|
|
///
|
|
|
|
/// In the future the signature of this function is expected to be:
|
|
|
|
/// ```
|
|
|
|
/// pub fn memoized<T: Clone, U: Clone, M: MutableMap<T, U>>(
|
|
|
|
/// cache: &RefCell<M>,
|
2015-02-01 11:44:15 -06:00
|
|
|
/// f: &|T| -> U
|
|
|
|
/// ) -> impl |T| -> U {
|
2014-10-14 13:41:50 -05:00
|
|
|
/// ```
|
|
|
|
/// but currently it is not possible.
|
|
|
|
///
|
|
|
|
/// # Example
|
|
|
|
/// ```
|
|
|
|
/// struct Context {
|
|
|
|
/// cache: RefCell<HashMap<uint, uint>>
|
|
|
|
/// }
|
|
|
|
///
|
|
|
|
/// fn factorial(ctxt: &Context, n: uint) -> uint {
|
|
|
|
/// memoized(&ctxt.cache, n, |n| match n {
|
|
|
|
/// 0 | 1 => n,
|
|
|
|
/// _ => factorial(ctxt, n - 2) + factorial(ctxt, n - 1)
|
|
|
|
/// })
|
|
|
|
/// }
|
|
|
|
/// ```
|
|
|
|
#[inline(always)]
|
2015-02-17 22:48:07 -06:00
|
|
|
pub fn memoized<T, U, S, F>(cache: &RefCell<HashMap<T, U, S>>, arg: T, f: F) -> U
|
|
|
|
where T: Clone + Hash + Eq,
|
|
|
|
U: Clone,
|
|
|
|
S: HashState,
|
|
|
|
F: FnOnce(T) -> U,
|
|
|
|
{
|
|
|
|
let key = arg.clone();
|
2015-02-22 10:13:41 -06:00
|
|
|
let result = cache.borrow().get(&key).cloned();
|
2015-02-17 22:48:07 -06:00
|
|
|
match result {
|
|
|
|
Some(result) => result,
|
|
|
|
None => {
|
|
|
|
let result = f(arg);
|
|
|
|
cache.borrow_mut().insert(key, result.clone());
|
|
|
|
result
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|