T0b1/wasmtime
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Tidy up whitespace.

Browse Source
This commit is contained in:
Dan Gohman
2018-03-04 22:37:34 -08:00
parent 0ea0146e58
commit c59e9180de
12 changed files with 33 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
lib/cretonne/src/bforest/path.rs
View File

@@ -285,7 +285,7 @@ impl<F: Forest> Path<F> {
fn split_and_insert(&mut self, mut key: F::Key, value: F::Value, pool: &mut NodePool<F>) {
let orig_root = self.node[0];
// Loop invariant: We need to split the node at `level` and then retry a failed insertion.
// Loop invariant: We need to split the node at `level` and then retry a failed insertion.
// The items to insert are either `(key, ins_node)` or `(key, value)`.
let mut ins_node = None;
let mut split;

10
lib/cretonne/src/divconst_magic_numbers.rs
View File

@@ -4,11 +4,11 @@
//----------------------------------------------------------------------
//
// Math helpers for division by (non-power-of-2) constants. This is based
// on the presentation in "Hacker's Delight" by Henry Warren, 2003. There
// are four cases: {unsigned, signed} x {32 bit, 64 bit}. The word size
// Math helpers for division by (non-power-of-2) constants. This is based
// on the presentation in "Hacker's Delight" by Henry Warren, 2003. There
// are four cases: {unsigned, signed} x {32 bit, 64 bit}. The word size
// makes little difference, but the signed-vs-unsigned aspect has a large
// effect. Therefore everything is presented in the order U32 U64 S32 S64
// effect. Therefore everything is presented in the order U32 U64 S32 S64
// so as to emphasise the similarity of the U32 and U64 cases and the S32
// and S64 cases.
@@ -478,7 +478,7 @@ mod tests {
fn test_magic_generators_dont_panic() {
// The point of this is to check that the magic number generators
// don't panic with integer wraparounds, especially at boundary
// cases for their arguments. The actual results are thrown away.
// cases for their arguments. The actual results are thrown away.
let mut total: u64 = 0;
println!("Testing UP magicU32");
for x in 2..(200 * 1000u32) {

2
lib/cretonne/src/legalizer/boundary.rs
View File

@@ -180,7 +180,7 @@ where
// We theoretically allow for call instructions that return a number of fixed results before
// the call return values. In practice, it doesn't happen.
let fixed_results = pos.func.dfg[call].opcode().constraints().fixed_results();
assert_eq!(fixed_results, 0, "Fixed results on calls not supported");
assert_eq!(fixed_results, 0, "Fixed results on calls not supported");
let results = pos.func.dfg.detach_results(call);
let mut next_res = 0;

18
lib/cretonne/src/preopt.rs
View File

@@ -20,7 +20,7 @@ use timing;
// Simple math helpers
// if `x` is a power of two, or the negation thereof, return the power along
// with a boolean that indicates whether `x` is negative. Else return None.
// with a boolean that indicates whether `x` is negative. Else return None.
#[inline]
fn isPowerOf2_S32(x: i32) -> Option<(bool, u32)> {
// We have to special-case this because abs(x) isn't representable.
@@ -128,10 +128,10 @@ fn get_div_info(inst: Inst, dfg: &DataFlowGraph) -> Option<DivRemByConstInfo> {
}
// TODO: should we actually bother to do this (that is, manually match
// the case that the second argument is an iconst)? Or should we assume
// the case that the second argument is an iconst)? Or should we assume
// that some previous constant propagation pass has pushed all such
// immediates to their use points, creating BinaryImm instructions
// instead? For now we take the conservative approach.
// instead? For now we take the conservative approach.
if let &InstructionData::Binary { opcode, args } = idata {
let (isSigned, isRem) = match opcode {
Opcode::Udiv => (false, false),
@@ -153,10 +153,10 @@ fn get_div_info(inst: Inst, dfg: &DataFlowGraph) -> Option<DivRemByConstInfo> {
}
// Actually do the transformation given a bundle containing the relevant
// information. `divrem_info` describes a div or rem by a constant, that
// information. `divrem_info` describes a div or rem by a constant, that
// `pos` currently points at, and `inst` is the associated instruction.
// `inst` is replaced by a sequence of other operations that calculate the
// same result. Note that there are various `divrem_info` cases where we
// same result. Note that there are various `divrem_info` cases where we
// cannot do any transformation, in which case `inst` is left unchanged.
fn do_divrem_transformation(divrem_info: &DivRemByConstInfo, pos: &mut FuncCursor, inst: Inst) {
let isRem = match *divrem_info {
@@ -234,7 +234,7 @@ fn do_divrem_transformation(divrem_info: &DivRemByConstInfo, pos: &mut FuncCurso
qf = q1;
}
}
// Now qf holds the final quotient. If necessary calculate the
// Now qf holds the final quotient. If necessary calculate the
// remainder instead.
if isRem {
let tt = pos.ins().imul_imm(qf, d as i64);
@@ -306,7 +306,7 @@ fn do_divrem_transformation(divrem_info: &DivRemByConstInfo, pos: &mut FuncCurso
qf = q1;
}
}
// Now qf holds the final quotient. If necessary calculate the
// Now qf holds the final quotient. If necessary calculate the
// remainder instead.
if isRem {
let tt = pos.ins().imul_imm(qf, d as i64);
@@ -382,7 +382,7 @@ fn do_divrem_transformation(divrem_info: &DivRemByConstInfo, pos: &mut FuncCurso
};
let t1 = pos.ins().ushr_imm(q3, 31);
let qf = pos.ins().iadd(q3, t1);
// Now qf holds the final quotient. If necessary calculate
// Now qf holds the final quotient. If necessary calculate
// the remainder instead.
if isRem {
let tt = pos.ins().imul_imm(qf, d as i64);
@@ -459,7 +459,7 @@ fn do_divrem_transformation(divrem_info: &DivRemByConstInfo, pos: &mut FuncCurso
};
let t1 = pos.ins().ushr_imm(q3, 63);
let qf = pos.ins().iadd(q3, t1);
// Now qf holds the final quotient. If necessary calculate
// Now qf holds the final quotient. If necessary calculate
// the remainder instead.
if isRem {
let tt = pos.ins().imul_imm(qf, d);