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

Correct some codegen stats counter inconsistencies #52171

Merged
merged 1 commit into from
Jul 11, 2018

Conversation

bharrisau
Copy link
Contributor

I noticed some possible typos/inconsistencies in the codegen counters. For example, fsub was getting counted as an integer sub, whereas fadd was counted as an add. And addincoming was only being counted on the initial call.

pub fn phi(&self, ty: Type, vals: &[ValueRef], bbs: &[BasicBlockRef]) -> ValueRef {
assert_eq!(vals.len(), bbs.len());
let phi = self.empty_phi(ty);
self.count_insn("addincoming");
unsafe {
llvm::LLVMAddIncoming(phi, vals.as_ptr(),
bbs.as_ptr(),
vals.len() as c_uint);
phi
}
}

Only remaining inconsistencies I can see are things like fadd_fast are counted as fadd. But the vector versions like vector_reduce_fmax_fast are counted as vector.reduce.fmax_fast not as their 'base' versions (vector_reduce_fmax is counted as vector.reduce.fmax).

@rust-highfive
Copy link
Collaborator

r? @estebank

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 9, 2018
@@ -1315,6 +1315,7 @@ impl<'a, 'tcx> Builder<'a, 'tcx> {
}

pub fn add_incoming_to_phi(&self, phi: ValueRef, val: ValueRef, bb: BasicBlockRef) {
self.count_insn("addincoming");
Copy link
Contributor

@estebank estebank Jul 9, 2018

Choose a reason for hiding this comment

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

There's already an addincoming

pub fn phi(&self, ty: Type, vals: &[ValueRef], bbs: &[BasicBlockRef]) -> ValueRef {
assert_eq!(vals.len(), bbs.len());
let phi = self.empty_phi(ty);
self.count_insn("addincoming");

I wonder wether the we want to differentiate between these two. Otherwise, r=me. CC @alexcrichton

Copy link
Contributor Author

@bharrisau bharrisau Jul 9, 2018

Choose a reason for hiding this comment

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

I didn't dig too far into it, but it looked like the phi gave you an object you can call add_to_phi on to add more items to. Both the phi and add_to_phi generate 1 AddIncoming instruction. Additionally, the phi call calls empty_phi which generates a BuildPhi instruction and increments the emptyphi instruction.

I added the count because it is generating that AddIncoming but only the initial phi was incrementing the counter.

Copy link
Member

Choose a reason for hiding this comment

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

Ah AFAIK these are all debugging counters anyway, so this should be fine!

@estebank
Copy link
Contributor

estebank commented Jul 9, 2018

@bors r+

@bors
Copy link
Contributor

bors commented Jul 9, 2018

📌 Commit aac0d91 has been approved by estebank

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 9, 2018
@estebank
Copy link
Contributor

estebank commented Jul 9, 2018

@bors rollup

Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request Jul 10, 2018
Correct some codegen stats counter inconsistencies

I noticed some possible typos/inconsistencies in the codegen counters. For example, `fsub` was getting counted as an integer `sub`, whereas `fadd` was counted as an add. And `addincoming` was only being counted on the initial call.

https://github.com/rust-lang/rust/blob/dbd10f81758381339f98994b8d31814cf5e98707/src/librustc_codegen_llvm/builder.rs#L831-L841

Only remaining inconsistencies I can see are things like `fadd_fast` are counted as `fadd`. But the vector versions like `vector_reduce_fmax_fast` are counted as `vector.reduce.fmax_fast` not as their 'base' versions (`vector_reduce_fmax` is counted as `vector.reduce.fmax`).
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Jul 10, 2018
Correct some codegen stats counter inconsistencies

I noticed some possible typos/inconsistencies in the codegen counters. For example, `fsub` was getting counted as an integer `sub`, whereas `fadd` was counted as an add. And `addincoming` was only being counted on the initial call.

https://github.com/rust-lang/rust/blob/dbd10f81758381339f98994b8d31814cf5e98707/src/librustc_codegen_llvm/builder.rs#L831-L841

Only remaining inconsistencies I can see are things like `fadd_fast` are counted as `fadd`. But the vector versions like `vector_reduce_fmax_fast` are counted as `vector.reduce.fmax_fast` not as their 'base' versions (`vector_reduce_fmax` is counted as `vector.reduce.fmax`).
bors added a commit that referenced this pull request Jul 10, 2018
Rollup of 7 pull requests

Successful merges:

 - #51612 (NLL: fix E0594 "change to mutable ref" suggestion)
 - #51722 (Updated RELEASES for 1.28.0)
 - #52064 (Clarifying how the alignment of the struct works)
 - #52149 (Add #[repr(transparent)] to Atomic* types)
 - #52151 (Trait impl settings)
 - #52171 (Correct some codegen stats counter inconsistencies)
 - #52195 (rustc: Avoid /tmp/ in graphviz writing)

Failed merges:

 - #52164 (use proper footnote syntax for references)

r? @ghost
@bors bors merged commit aac0d91 into rust-lang:master Jul 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants