Skip to content

Commit c3d4b25

Browse files
authored
Merge pull request #25 from Veykril/veykril/push-pmsywwtwmtvv
Remove trailing whitespaces
2 parents eab1c6c + 690ec4f commit c3d4b25

File tree

1 file changed

+6
-6
lines changed

1 file changed

+6
-6
lines changed

README.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -257,7 +257,7 @@ Medium.
257257

258258
**Description**
259259

260-
Over the last year, support for automatic differentiation ('autodiff') was added to the Rust compiler. The autodiff tool which we are using ([Enzyme](https://enzyme.mit.edu/)) operates
260+
Over the last year, support for automatic differentiation ('autodiff') was added to the Rust compiler. The autodiff tool which we are using ([Enzyme](https://enzyme.mit.edu/)) operates
261261
on LLVM-IR, which is the intermediate representation of code, used by LLVM. LLVM is the default backend of the Rust compiler. Unfortunately, two layout related problems limit its usability.
262262

263263
A) The Rust compiler has a set of ABI optimizations which can improve performance, but make it harder for autodiff to work. An example is the function `fn foo(a: f32, b: f32) -> f32`,
@@ -267,7 +267,7 @@ If a function has a `#[rustc_autodiff]` attribute, the Rust compiler should simp
267267
Multiple examples of function headers which will get handled incorrectly at the moment are listed [here](https://github.com/EnzymeAD/rust/issues/105).
268268

269269
B) Enzyme requires good information about the memory layout of types, both to be able to differentiate the code, and to do so efficiently. In order to help Enzyme,
270-
we want to lower more Type Information from MIR or even THIR into LLVM-IR metadata, or make better usage of existing debug info. If you are interested in this part and
270+
we want to lower more Type Information from MIR or even THIR into LLVM-IR metadata, or make better usage of existing debug info. If you are interested in this part and
271271
also have some LLVM experience, please have a look at the LLVM website for the related proposal.
272272

273273
For both A) and B), the online compiler explorer [here](https://enzyme.mit.edu/explorer/) can be used to trigger both types of bugs, to get a feeling for existing problems.
@@ -310,11 +310,11 @@ Currently, the backend end (codegen part) of the compiler has been parallelized,
310310
The most important and valuable work in this area are two aspects:
311311

312312
A) Diagnosing and fixing deadlock [issues](https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AWG-compiler-parallel+deadlock) caused by the execution order of compiler queries in a multithreaded environment.
313-
[Queries](https://rustc-dev-guide.rust-lang.org/query.html) is a unique design of the Rust compiler, which is used to achieve incremental compilation process. It divides the compiler
314-
process into various parts and caches the execution results of each part. However, queries caching dependencies between multiple threads may cause deadlock.
313+
[Queries](https://rustc-dev-guide.rust-lang.org/query.html) is a unique design of the Rust compiler, which is used to achieve incremental compilation process. It divides the compiler
314+
process into various parts and caches the execution results of each part. However, queries caching dependencies between multiple threads may cause deadlock.
315315
[`Work-stealing`](https://en.wikipedia.org/wiki/Work_stealing), a method used to improve parallelization performance, is the core reason.
316316

317-
To solve these problems, we need to find the part of the compiler process that causes deadlock through diagnosing coredumps in issues, and adjusting the execution order
317+
To solve these problems, we need to find the part of the compiler process that causes deadlock through diagnosing coredumps in issues, and adjusting the execution order
318318
of this part of code so that there will be no circular dependencies on the query caches between multiple threads. This [PR](https://github.com/rust-lang/rust/pull/118488) is a good example of solving a deadlock problem.
319319

320320
B) Improving the performance of the parallel frontend
@@ -833,5 +833,5 @@ Some of the work is medium. Diagnosing and / or fixing failures is often pretty
833833

834834
**Further resources**
835835

836-
- [Wild linker](https://github.com/davidlattimore/wild)
836+
- [Wild linker](https://github.com/davidlattimore/wild)
837837
- [Blog posts, most of which are about Wild](https://davidlattimore.github.io/)

0 commit comments

Comments
 (0)