Repository navigation
Bad native codegen (2017-12-25 Nightly) #47015
Copy link
Copy link
Closed
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.I-slowIssue: Problems and improvements with respect to performance of generated code.Issue: Problems and improvements with respect to performance of generated code.
Description
Activity
This looks like a bug in LLVM unfortunately. For example:
$ opt input.ll -S -O2 -mcpu=haswell -o output.ll$ opt output.ll -s -O2 ; ModuleID = '<stdin>' source_filename = "a.ll" target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" ; Function Attrs: norecurse nounwind readnone define i64 @foo() local_unnamed_addr #0 { start: ret i64 9246255105 } attributes #0 = { norecurse nounwind readnone "target-cpu"="haswell" }The major change in the nightly here is that ThinLTO was enabled. ThinLTO can run optimizations twice (why
optis run twice here) and it seems as if some bug is generating this answer.Using LLVM trunk the intermediate result is the same and the second optimization pass generates
ret i64 8739992577instead of the previous number (which is what we'd expect).As a result this is probably just a bland "already fixed in LLVM" bug, making this blocked on #43370
- addedA-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
on Dec 26, 2017 - addedI-slowIssue: Problems and improvements with respect to performance of generated code.Issue: Problems and improvements with respect to performance of generated code.
on Jan 7, 2018 - added a commit that references this issue
on Jan 28, 2018 - added a commit that references this issue
on Jan 28, 2018 - added a commit that references this issue
on Jan 30, 2018 8 remaining items
- added 3 commits that reference this issue
on Feb 7, 2018 - added a commit that references this issue
on Feb 9, 2018 - added a commit that references this issue
on Feb 10, 2018 - added a commit that references this issue
on Feb 10, 2018
Metadata
Metadata
Assignees
Labels
A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.I-slowIssue: Problems and improvements with respect to performance of generated code.Issue: Problems and improvements with respect to performance of generated code.
Given this small program:
I am using:
If I compile that program with this it works correctly:
rustc -C opt-level=1 test.rsIf I compile it with a native CPU target it asserts:
rustc -C opt-level=1 -C target-cpu=native test.rsThe llvm-ir of the e97 function produced with a default CPU target:
And the llvm-ir using the native CPU target:
Their diff: