From evan.cheng at apple.com Mon Mar 24 00:28:39 2008 From: evan.cheng at apple.com (Evan Cheng) Date: Mon, 24 Mar 2008 05:28:39 -0000 Subject: [llvm-commits] [llvm] r48720 - /llvm/trunk/lib/Transforms/Scalar/GVN.cpp Message-ID: <200803240528.m2O5Sdgf005711@zion.cs.uiuc.edu> Author: evancheng Date: Mon Mar 24 00:28:38 2008 New Revision: 48720 URL: http://llvm.org/viewvc/llvm-project?rev=48720&view=rev Log: Temporarily disabling memset forming optimization. Add an option. Modified: llvm/trunk/lib/Transforms/Scalar/GVN.cpp Modified: llvm/trunk/lib/Transforms/Scalar/GVN.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/GVN.cpp?rev=48720&r1=48719&r2=48720&view=diff ============================================================================== --- llvm/trunk/lib/Transforms/Scalar/GVN.cpp (original) +++ llvm/trunk/lib/Transforms/Scalar/GVN.cpp Mon Mar 24 00:28:38 2008 @@ -32,6 +32,7 @@ #include "llvm/Analysis/AliasAnalysis.h" #include "llvm/Analysis/MemoryDependenceAnalysis.h" #include "llvm/Support/CFG.h" +#include "llvm/Support/CommandLine.h" #include "llvm/Support/Compiler.h" #include "llvm/Support/GetElementPtrTypeIterator.h" #include "llvm/Target/TargetData.h" @@ -41,6 +42,12 @@ STATISTIC(NumGVNLoad, "Number of loads deleted"); STATISTIC(NumMemSetInfer, "Number of memsets inferred"); +namespace { + cl::opt + FormMemSet("form-memset-from-stores", + cl::desc("Transform straight-line stores to memsets"), + cl::init(false), cl::Hidden); +} //===----------------------------------------------------------------------===// // ValueTable Class @@ -1102,6 +1109,7 @@ /// neighboring locations of memory. If it sees enough consequtive ones /// (currently 4) it attempts to merge them together into a memcpy/memset. bool GVN::processStore(StoreInst *SI, SmallVectorImpl &toErase) { + if (!FormMemSet) return false; if (SI->isVolatile()) return false; // There are two cases that are interesting for this code to handle: memcpy From dpatel at apple.com Mon Mar 24 00:35:41 2008 From: dpatel at apple.com (Devang Patel) Date: Mon, 24 Mar 2008 05:35:41 -0000 Subject: [llvm-commits] [llvm] r48721 - /llvm/trunk/docs/LangRef.html Message-ID: <200803240535.m2O5ZfB0006095@zion.cs.uiuc.edu> Author: dpatel Date: Mon Mar 24 00:35:41 2008 New Revision: 48721 URL: http://llvm.org/viewvc/llvm-project?rev=48721&view=rev Log: Update Function type documentation to clarify how multiple return values are supported. Modified: llvm/trunk/docs/LangRef.html Modified: llvm/trunk/docs/LangRef.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/LangRef.html?rev=48721&r1=48720&r2=48721&view=diff ============================================================================== --- llvm/trunk/docs/LangRef.html (original) +++ llvm/trunk/docs/LangRef.html Mon Mar 24 00:35:41 2008 @@ -1225,8 +1225,10 @@
Overview:

The function type can be thought of as a function signature. It -consists of a return type and a list of formal parameter types. -Function types are usually used to build virtual function tables +consists of a return type and a list of formal parameter types. The +return type of a function type is a scalar type or a struct type. If the +return type is a struct type then all struct elements must be of a first +class type. Function types are usually used to build virtual function tables (which are structures of pointers to functions), for indirect function calls, and when defining a function.

@@ -1260,6 +1262,11 @@ which returns an integer. This is the signature for printf in LLVM. + + {i32, i32} (i32) + A function taking an i32>, returning two values + i32 as an arggregate of type { i32, i32 } + From isanbard at gmail.com Mon Mar 24 00:55:54 2008 From: isanbard at gmail.com (Bill Wendling) Date: Mon, 24 Mar 2008 05:55:54 -0000 Subject: [llvm-commits] [llvm] r48722 - /llvm/trunk/tools/llvmc2/doc/LLVMC-Enhancements.rst Message-ID: <200803240555.m2O5tsE2006815@zion.cs.uiuc.edu> Author: void Date: Mon Mar 24 00:55:54 2008 New Revision: 48722 URL: http://llvm.org/viewvc/llvm-project?rev=48722&view=rev Log: Grammar Nazi strikes! :-) Modified: llvm/trunk/tools/llvmc2/doc/LLVMC-Enhancements.rst Modified: llvm/trunk/tools/llvmc2/doc/LLVMC-Enhancements.rst URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvmc2/doc/LLVMC-Enhancements.rst?rev=48722&r1=48721&r2=48722&view=diff ============================================================================== --- llvm/trunk/tools/llvmc2/doc/LLVMC-Enhancements.rst (original) +++ llvm/trunk/tools/llvmc2/doc/LLVMC-Enhancements.rst Mon Mar 24 00:55:54 2008 @@ -7,56 +7,55 @@ Motivation ========== -As it stands, current version of LLVMC does not meet its stated goals -of configurability and extensibility and is therefore not used -much. The need for enhancements in LLVMC is also reflected in [1]_. The +As it stands, the current version of LLVMC does not meet its stated goals +of configurability and extensibility, and is therefore not used +much. The need for enhancements to LLVMC is also reflected in [1]_. The proposed rewrite will fix the aforementioned deficiences and provide an extensible, future-proof solution. Design ====== -A compiler driver's job is essentially to find a way how to transform -a set of input files into a set of targets, depending on the -user-provided options. Since several ways of transformation can exist -potentially, it's natural to use a directed graph to represent all of -them. In this graph, nodes are tools (for example, ``gcc -S`` is a tool -that generates assembly from C language files) and edges between them -mean that the output of one tool can be given as input to another (as -in ``gcc -S -o - file.c | as``). We'll call this graph the compilation -graph. +A compiler driver's job is essentially to find a way to transform a set +of input files into a set of targets, depending on the user-provided +options. Since several methods of transformation can potentially exist, +it's natural to use a directed graph to represent all of them. In this +graph, nodes are tools -- e.g., ``gcc -S`` is a tool that generates +assembly from C language files -- and edges between the nodes indicate +that the output of one tool can be given as input to another -- i.e., +``gcc -S -o - file.c | as``. We'll call this graph the compilation graph. The proposed design revolves around the compilation graph and the following core abstractions: - Target - An (intermediate) compilation target. -- Action - A shell command template that represents basic compilation - transformation(example: ``gcc -S $INPUT_FILE -o $OUTPUT_FILE``). +- Action - A shell command template that represents a basic compilation + transformation -- example: ``gcc -S $INPUT_FILE -o $OUTPUT_FILE``. - Tool - Encapsulates information about a concrete tool used in the - compilation process, produces Actions. Operation depends on + compilation process, produces Actions. Its operation depends on command-line options provided by the user. -- GraphBuilder - Constructs the compilation graph, operation depends - on command-line options. +- GraphBuilder - Constructs the compilation graph. Its operation + depends on command-line options. - GraphTraverser - Traverses the compilation graph and constructs a - sequence of Actions needed to build the target file, operation + sequence of Actions needed to build the target file. Its operation depends on command-line options. A high-level view of the compilation process: 1. Configuration libraries (see below) are loaded in and the - compilation graph is constructed from the tool descriptions. + compilation graph is constructed from the tool descriptions. 2. Information about possible options is gathered from (the nodes of) - the compilation graph. + the compilation graph. 3. Options are parsed based on data gathered in step 2. 4. A sequence of Actions needed to build the target is constructed - using the compilation graph and provided options. + using the compilation graph and provided options. 5. The resulting action sequence is executed. @@ -65,8 +64,8 @@ To make this design extensible, TableGen [2]_ will be used for automatic generation of the Tool classes. Users wanting to customize -LLVMC will need to write a configuration library consisting of a set -of TableGen descriptions of compilation tools plus a number of hooks +LLVMC need to write a configuration library consisting of a set of +TableGen descriptions of compilation tools plus a number of hooks that influence compilation graph construction and traversal. LLVMC will have the ability to load user configuration libraries at runtime; in fact, its own basic functionality will be implemented as a @@ -76,7 +75,7 @@ ------------------------------ This small example specifies a Tool that converts C source to object -files. Note that it is only a mock-up of inteded functionality, not a +files. Note that it is only a mock-up of intended functionality, not a final specification:: def GCC : Tool< @@ -192,15 +191,15 @@ Option handling =============== -Since one of the main tasks of the compiler driver is to correctly +Because one of the main tasks of the compiler driver is to correctly handle user-provided options, it is important to define this process -in exact way. The intent of the proposed scheme is to function as a -drop-in replacement for GCC. +in an exact way. The intent of the proposed scheme is to function as +a drop-in replacement for GCC. Option syntax ------------- -Option syntax is specified by the following formal grammar:: +The option syntax is specified by the following formal grammar:: ::=