derek.holloway
7502bf64a4
CodeQL / Analyze (actions) (push) Canceled after 0s
CodeQL / Analyze (python) (push) Canceled after 0s
pre-commit / pre-commit (push) Canceled after 0s
Multi-Arch CI / setup (push) Canceled after 0s
Publish build_manylinux_x86_64 images / publish_build_manylinux_x86_64 (push) Canceled after 0s
Setup (Multi-Arch) / setup (push) Canceled after 0s
Multi-Arch CI / Linux::${{ fromJSON(needs.setup.outputs.linux_build_config || '{}').build_variant_label || 'skip' }} (push) Canceled after 0s
Publish TheRock Docker image / build-and-push-image (push) Canceled after 0s
Publish no_rocm_image_ubi10 image / publish_no_rocm_image_ubi10 (push) Canceled after 0s
Multi-Arch CI / Windows::${{ fromJSON(needs.setup.outputs.windows_build_config || '{}').build_variant_label || 'skip' }} (push) Canceled after 0s
Publish TheRock Docker image / build-and-push-image (push) Canceled after 0s
Multi-Arch CI / Manifest Diff (push) Canceled after 0s
TheRock Manifest Diff Report / Generate Manifest Diff Report (push) Canceled after 0s
Multi-Arch CI / CI Summary (push) Canceled after 0s
Publish no_rocm_image_ubuntu24_04 images / publish_no_rocm_image_ubuntu24_04 (push) Canceled after 0s
Publish no_rocm_image_ubuntu24_04_ocl_rt images / publish_no_rocm_image_ubuntu24_04_ocl_rt (push) Canceled after 0s
Publish TheRock Docker image / build-and-push-image (push) Canceled after 0s
Publish TheRock Docker image / build-and-push-image (push) Canceled after 0s
Publish no_rocm_image_ubuntu24_04 images / publish_no_rocm_image_ubuntu24_04_rocgdb (push) Canceled after 0s
Publish no_rocm_image_ubuntu24_04_rocgdb images / publish_no_rocm_image_ubuntu24_04_rocgdb (push) Canceled after 0s
Publish no_rocm_image_ubuntu24_04 images / publish_no_rocm_image_ubuntu24_04_ocl_rt (push) Canceled after 0s
Publish TheRock Docker image / build-and-push-image (push) Canceled after 0s
Unit Tests / Unit Tests :: ubuntu-24.04 (push) Canceled after 0s
Unit Tests / Unit Tests :: windows-2022 (push) Canceled after 0s
Publish no_rocm_image_ubuntu24_04 images / publish_no_rocm_image_ubuntu24_04_media (push) Canceled after 0s
Unit Tests / Unit Tests Summary (push) Canceled after 0s
Publish no_rocm_image_ubuntu24_04 images / publish_no_rocm_image_ubuntu24_04_openmpi (push) Canceled after 0s
72 lines
2.9 KiB
Plaintext
72 lines
2.9 KiB
Plaintext
Date: Fri, 1 Jun 2001 17:08:44 -0500 (CDT)
|
|
From: Chris Lattner <sabre@nondot.org>
|
|
To: Vikram S. Adve <vadve@cs.uiuc.edu>
|
|
Subject: RE: Interesting: GCC passes
|
|
|
|
> That is very interesting. I agree that some of these could be done on LLVM
|
|
> at link-time, but it is the extra time required that concerns me. Link-time
|
|
> optimization is severely time-constrained.
|
|
|
|
If we were to reimplement any of these optimizations, I assume that we
|
|
could do them a translation unit at a time, just as GCC does now. This
|
|
would lead to a pipeline like this:
|
|
|
|
Static optimizations, xlation unit at a time:
|
|
.c --GCC--> .llvm --llvmopt--> .llvm
|
|
|
|
Link time optimizations:
|
|
.llvm --llvm-ld--> .llvm --llvm-link-opt--> .llvm
|
|
|
|
Of course, many optimizations could be shared between llvmopt and
|
|
llvm-link-opt, but the wouldn't need to be shared... Thus compile time
|
|
could be faster, because we are using a "smarter" IR (SSA based).
|
|
|
|
> BTW, about SGI, "borrowing" SSA-based optimizations from one compiler and
|
|
> putting it into another is not necessarily easier than re-doing it.
|
|
> Optimization code is usually heavily tied in to the specific IR they use.
|
|
|
|
Understood. The only reason that I brought this up is because SGI's IR is
|
|
more similar to LLVM than it is different in many respects (SSA based,
|
|
relatively low level, etc), and could be easily adapted. Also their
|
|
optimizations are written in C++ and are actually somewhat
|
|
structured... of course it would be no walk in the park, but it would be
|
|
much less time consuming to adapt, say, SSA-PRE than to rewrite it.
|
|
|
|
> But your larger point is valid that adding SSA based optimizations is
|
|
> feasible and should be fun. (Again, link time cost is the issue.)
|
|
|
|
Assuming linktime cost wasn't an issue, the question is:
|
|
Does using GCC's backend buy us anything?
|
|
|
|
> It also occurs to me that GCC is probably doing quite a bit of back-end
|
|
> optimization (step 16 in your list). Do you have a breakdown of that?
|
|
|
|
Not really. The irritating part of GCC is that it mixes it all up and
|
|
doesn't have a clean separation of concerns. A lot of the "back end
|
|
optimization" happens right along with other data optimizations (ie, CSE
|
|
of machine specific things).
|
|
|
|
As far as REAL back end optimizations go, it looks something like this:
|
|
|
|
1. Instruction combination: try to make CISCy instructions, if available
|
|
2. Register movement: try to get registers in the right places for the
|
|
architecture to avoid register to register moves. For example, try to get
|
|
the first argument of a function to naturally land in %o0 for sparc.
|
|
3. Instruction scheduling: 'nuff said :)
|
|
4. Register class preferencing: ??
|
|
5. Local register allocation
|
|
6. global register allocation
|
|
7. Spilling
|
|
8. Local regalloc
|
|
9. Jump optimization
|
|
10. Delay slot scheduling
|
|
11. Branch shorting for CISC machines
|
|
12. Instruction selection & peephole optimization
|
|
13. Debug info output
|
|
|
|
But none of this would be usable for LLVM anyways, unless we were using
|
|
GCC as a static compiler.
|
|
|
|
-Chris
|
|
|