In the LLVM 3.2 time-frame, the Clang team has made many improvements.
Highlights include:
-#. ...
+#. More powerful warnings, especially `-Wuninitialized`
+#. Template type diffing in diagnostic messages
+#. Higher quality and more efficient debug info generation
For more details about the changes to Clang since the 3.1 release, see the
`Clang release notes. <http://clang.llvm.org/docs/ReleaseNotes.html>`_
The 3.2 release has the following notable changes:
-#. ...
+#. Able to load LLVM plugins such as Polly.
+#. Supports thread-local storage models.
+#. Passes knowledge of variable lifetimes to the LLVM optimizers.
+#. No longer requires GCC to be built with LTO support.
compiler-rt: Compiler Runtime Library
-------------------------------------
strong phi elim
loop dependence analysis
CorrelatedValuePropagation
- lib/Transforms/IPO/MergeFunctions.cpp => consider for 3.2.
Integrated assembler on by default for arm/thumb?
Near dead:
'``noalias``' and are checked at runtime.
#. ...
-SROA - We've re-written SROA to be significantly more powerful.
+SROA - We've re-written SROA to be significantly more powerful and generate
+code which is much more friendly to the rest of the optimization pipeline.
+Previously this pass had scaling problems that required it to only operate on
+relatively small aggregates, and at times it would mistakenly replace a large
+aggregate with a single very large integer in order to make it a scalar SSA
+value. The result was a large number of i1024 and i2048 values representing any
+small stack buffer. These in turn slowed down many subsequent optimization
+paths.
+
+The new SROA pass uses a different algorithm that allows it to only promote to
+scalars the pieces of the aggregate actively in use. Because of this it doesn't
+require any thresholds. It also always deduces the scalar values from the uses
+of the aggregate rather than the specific LLVM type of the aggregate. These
+features combine to both optimize more code with the pass but to improve the
+compile time of many functions dramatically.
#. Branch weight metadata is preseved through more of the optimizer.
#. ...
Target Independent Code Generator Improvements
----------------------------------------------
-Stack Coloring - We have implemented a new optimization pass to merge stack
-objects which are used in disjoin areas of the code. This optimization reduces
-the required stack space significantly, in cases where it is clear to the
-optimizer that the stack slot is not shared. We use the lifetime markers to
-tell the codegen that a certain alloca is used within a region.
-
-We now merge consecutive loads and stores.
-
We have put a significant amount of work into the code generator
infrastructure, which allows us to implement more aggressive algorithms and
make it run faster:
#. ...
-We added new TableGen infrastructure to support bundling for Very Long
-Instruction Word (VLIW) architectures. TableGen can now automatically generate
-a deterministic finite automaton from a VLIW target's schedule description
-which can be queried to determine legal groupings of instructions in a bundle.
-
-We have added a new target independent VLIW packetizer based on the DFA
-infrastructure to group machine instructions into bundles.
-
-Basic Block Placement
-^^^^^^^^^^^^^^^^^^^^^
+Stack Coloring - We have implemented a new optimization pass to merge stack
+objects which are used in disjoin areas of the code. This optimization reduces
+the required stack space significantly, in cases where it is clear to the
+optimizer that the stack slot is not shared. We use the lifetime markers to
+tell the codegen that a certain alloca is used within a region.
-A probability based block placement and code layout algorithm was added to
-LLVM's code generator. This layout pass supports probabilities derived from
-static heuristics as well as source code annotations such as
-``__builtin_expect``.
+We now merge consecutive loads and stores.
X86-32 and X86-64 Target Improvements
-------------------------------------
.. _armintegratedassembler:
-ARM Integrated Assembler
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-The ARM target now includes a full featured macro assembler, including
-direct-to-object module support for clang. The assembler is currently enabled
-by default for Darwin only pending testing and any additional necessary
-platform specific support for Linux.
-
-Full support is included for Thumb1, Thumb2 and ARM modes, along with subtarget
-and CPU specific extensions for VFP2, VFP3 and NEON.
-
-The assembler is Unified Syntax only (see ARM Architecural Reference Manual for
-details). While there is some, and growing, support for pre-unfied (divided)
-syntax, there are still significant gaps in that support.
-
MIPS Target Improvements
------------------------
Known problem areas include:
-#. The CellSPU, MSP430, and XCore backends are experimental.
+#. The MSP430 and XCore backends are experimental.
#. The integrated assembler, disassembler, and JIT is not supported by several
targets. If an integrated assembler is not supported, then a system
projects / oota-llvm.git / blobdiff