Sections:

+ + + The LLVM Compiler Infrastructure + + Last modified: $Date: 2011-10-31 12:50:0 -0700 (Mon, 31 Oct 2011) $ + · buildslave-root-directory

llvm.exp.*
http://lab.llvm.org:8011
http://trac.buildbot.net/
lab.llvm.org port 9990
http://buildbot.net/buildbot/docs/current/full.html#creating-a-slave
+      $ buildslave create-slave buildslave-root-directory lab.llvm.org: 9990 \
+      buildslave-access-name buildslave-access-password
+      
+           Windows 7 x64
+           Core i7 (2.66GHz), 16GB of RAM
+           
+           g++.exe (TDM-1 mingw32) 4.4.0
+           GNU Binutils 2.19.1
+           cmake version 2.8.4
+           Microsoft(R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
+      
http://llvm.org/svn/llvm-project/zorg/trunk/buildbot/osuosl/master/config/slaves.py
http://llvm.org/svn/llvm-project/zorg/trunk/buildbot/osuosl/master/config/builders.py
llvm-config
llvm-config
.a
.o
.o
.o
LLVMLIBS
.a
lib
LLVMLIBS
.a
.a
.a
.a
.a
.a
.a
.a
.a
.a
.a
.o
.a
.a
.a
.a
.a
.o
.o
.o
.o
.o
.o
.a
.o
.o
.o
.o
llvm-config
llvm-config
llvm-config
--ldflags
ld
-L
--libs
--libnames
--libfiles
llvm-config
GenLibDeps.pl
utils
LLVMCore LLVMSupport.a LLVMSystem.a
LLVM
.o
.a
llvm/
llvm/
http://lab.llvm.org:8011
http://trac.buildbot.net/
lab.llvm.org port 9990
http://buildbot.net/buildbot/docs/current/full.html#creating-a-slave
            Windows 7 x64
            Core i7 (2.66GHz), 16GB of RAM
-           
+
            g++.exe (TDM-1 mingw32) 4.4.0
            GNU Binutils 2.19.1
            cmake version 2.8.4
@@ -87,7 +89,7 @@
 
   Make sure you can actually start the buildslave successfully. Then set 
       up your build slave to start automatically at the start up time.
-      See buildbot manual for help.
+      See buildbot manual for help. You may want to restart your computer to see if it works.
http://buildbot.net/buildbot/docs/current/full.html#creating-a-slave
-      $ buildslave create-slave buildslave-root-directory lab.llvm.org: 9990 \
-      buildslave-access-name buildslave-access-password
-      
-           Windows 7 x64
-           Core i7 (2.66GHz), 16GB of RAM
-
-           g++.exe (TDM-1 mingw32) 4.4.0
-           GNU Binutils 2.19.1
-           cmake version 2.8.4
-           Microsoft(R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
-      
http://llvm.org/svn/llvm-project/zorg/trunk/buildbot/osuosl/master/config/slaves.py
http://llvm.org/svn/llvm-project/zorg/trunk/buildbot/osuosl/master/config/builders.py
+$ buildslave create-slave buildslave-root-directory \
+             lab.llvm.org:9990 \
+             buildslave-access-name buildslave-access-password
+
+Windows 7 x64
+Core i7 (2.66GHz), 16GB of RAM
+
+g++.exe (TDM-1 mingw32) 4.4.0
+GNU Binutils 2.19.1
+cmake version 2.8.4
+Microsoft(R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
+
buildbot/osuosl/master/config/slaves.py
buildbot/osuosl/master/config/builders.py
LLVMBuild
LLVMBuild.txt
LLVMBuild.txt
LLVMBuild.txt
+; Comments start with a semi-colon.
+
+; Sections are declared using square brackets.
+[component 0]
+
+; Properties are declared using '=' and are contained in the previous section.
+;
+; We support simple scalar values and list values, where items are separated by
+; spaces. There is no support for quoting, and so property values may not contain
+; spaces.
+property_name = property_value
+list_property_name = value_1 value_2 ... value_n
+
+[component_0]
+type = Library
+name = Linker
+parent = Libraries
+required_libraries = Archive BitReader Core Support TransformUtils
+
llvm/
odr
external
external
unnamed_addr



From evan.cheng at apple.com  Fri Nov  4 15:44:53 2011
From: evan.cheng at apple.com (Evan Cheng)
Date: Fri, 04 Nov 2011 13:44:53 -0700
Subject: [llvm-commits] LoadSDNode invariance
In-Reply-To: <72DEEAEF-7CA4-45AF-9286-0ADD7082EB96@apple.com>
References: <72DEEAEF-7CA4-45AF-9286-0ADD7082EB96@apple.com>
Message-ID: <0CD49991-E497-4531-8554-E9168E566EB4@apple.com>


On Nov 4, 2011, at 11:56 AM, Peter Cooper wrote:

> Hi
> 
> I've added new metadata to load IR instructions to say if they are invariant, i.e., don't change at runtime.
> 
> The IR change was simple but i'm not sure about the MachineInstr/DAG level.  I've attached the change which encodes the invariant flag in the MemSDNodeFlags next to the volatile flag.
> 
> Please have a look and tell me if this is ideal?  The main thing i wasn't happy doing was adding another DAG.getLoad method with the invariant flag, but the alternative was changing the existing method which would lead to changing dozens of calls.

If it's only dozens of calls, then I vote for changing the existing method.

Evan

> 
> Thanks,
> Pete
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits


From peter_cooper at apple.com  Fri Nov  4 15:52:14 2011
From: peter_cooper at apple.com (Peter Cooper)
Date: Fri, 04 Nov 2011 13:52:14 -0700
Subject: [llvm-commits] LoadSDNode invariance
In-Reply-To: <0CD49991-E497-4531-8554-E9168E566EB4@apple.com>
References: <72DEEAEF-7CA4-45AF-9286-0ADD7082EB96@apple.com>
	<0CD49991-E497-4531-8554-E9168E566EB4@apple.com>
Message-ID: 

I'm happy doing that.  Hopefully it doesn't end up as too many changes for people with their own backends.

Pete

On Nov 4, 2011, at 1:44 PM, Evan Cheng wrote:

> 
> On Nov 4, 2011, at 11:56 AM, Peter Cooper wrote:
> 
>> Hi
>> 
>> I've added new metadata to load IR instructions to say if they are invariant, i.e., don't change at runtime.
>> 
>> The IR change was simple but i'm not sure about the MachineInstr/DAG level.  I've attached the change which encodes the invariant flag in the MemSDNodeFlags next to the volatile flag.
>> 
>> Please have a look and tell me if this is ideal?  The main thing i wasn't happy doing was adding another DAG.getLoad method with the invariant flag, but the alternative was changing the existing method which would lead to changing dozens of calls.
> 
> If it's only dozens of calls, then I vote for changing the existing method.
> 
> Evan
> 
>> 
>> Thanks,
>> Pete
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 


From bruno.cardoso at gmail.com  Fri Nov  4 17:24:36 2011
From: bruno.cardoso at gmail.com (Bruno Cardoso Lopes)
Date: Fri, 04 Nov 2011 22:24:36 -0000
Subject: [llvm-commits] [llvm] r143738 -
	/llvm/trunk/lib/MC/ELFObjectWriter.cpp
Message-ID: <20111104222436.C0D222A6C12C@llvm.org>

Author: bruno
Date: Fri Nov  4 17:24:36 2011
New Revision: 143738

URL: http://llvm.org/viewvc/llvm-project?rev=143738&view=rev
Log:
Add mips ELF relocation types. Patch by Jack Carter!

Modified:
    llvm/trunk/lib/MC/ELFObjectWriter.cpp

Modified: llvm/trunk/lib/MC/ELFObjectWriter.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/MC/ELFObjectWriter.cpp?rev=143738&r1=143737&r2=143738&view=diff
==============================================================================

--- llvm/trunk/lib/MC/ELFObjectWriter.cpp (original)
+++ llvm/trunk/lib/MC/ELFObjectWriter.cpp Fri Nov  4 17:24:36 2011
@@ -28,6 +28,7 @@
 #include "llvm/ADT/Statistic.h"
 #include "llvm/ADT/StringSwitch.h"
 
+#include "../Target/Mips/MCTargetDesc/MipsFixupKinds.h"
 #include "../Target/X86/MCTargetDesc/X86FixupKinds.h"
 #include "../Target/ARM/MCTargetDesc/ARMFixupKinds.h"
 #include "../Target/PowerPC/MCTargetDesc/PPCFixupKinds.h"
@@ -277,7 +278,7 @@
                                        MCDataFragment *ShndxF,
                                        const MCAssembler &Asm,
                                        const MCAsmLayout &Layout,
-                                     const SectionIndexMapTy &SectionIndexMap) {
+                                    const SectionIndexMapTy &SectionIndexMap) {
   // The string table must be emitted first because we need the index
   // into the string table for all the symbol names.
   assert(StringTable.size() && "Missing string table");
@@ -306,7 +307,8 @@
         Section.getType() == ELF::SHT_SYMTAB_SHNDX)
       continue;
     WriteSymbolEntry(SymtabF, ShndxF, 0, ELF::STT_SECTION, 0, 0,
-                     ELF::STV_DEFAULT, SectionIndexMap.lookup(&Section), false);
+                     ELF::STV_DEFAULT, SectionIndexMap.lookup(&Section),
+                     false);
     LastLocalSymbolIndex++;
   }
 
@@ -416,7 +418,7 @@
       // Offset of the symbol in the section
       int64_t a = Layout.getSymbolOffset(&SDB);
 
-      // Ofeset of the relocation in the section
+      // Offset of the relocation in the section
       int64_t b = Layout.getFragmentOffset(Fragment) + Fixup.getOffset();
       Value += b - a;
     }
@@ -1273,7 +1275,6 @@
   }
 }
 
-
 /// START OF SUBCLASSES for ELFObjectWriter
 //===- ARMELFObjectWriter -------------------------------------------===//
 
@@ -1815,6 +1816,8 @@
   return Type;
 }
 
+//===- MipsELFObjectWriter -------------------------------------------===//
+
 MipsELFObjectWriter::MipsELFObjectWriter(MCELFObjectTargetWriter *MOTW,
                                          raw_ostream &_OS,
                                          bool IsLittleEndian)
@@ -1827,6 +1830,52 @@
                                            bool IsPCRel,
                                            bool IsRelocWithSymbol,
                                            int64_t Addend) {
-  // tbd
-  return 1;
+  // determine the type of the relocation
+  unsigned Type = (unsigned)ELF::R_MIPS_NONE;
+  unsigned Kind = (unsigned)Fixup.getKind();
+
+  switch (Kind) {
+  default:
+    llvm_unreachable("invalid fixup kind!");
+  case FK_Data_4:
+    Type = ELF::R_MIPS_32;
+    break;
+  case Mips::fixup_Mips_GPREL16:
+    Type = ELF::R_MIPS_GPREL16;
+    break;
+  case Mips::fixup_Mips_26:
+    Type = ELF::R_MIPS_26;
+    break;
+  case Mips::fixup_Mips_CALL16:
+    Type = ELF::R_MIPS_CALL16;
+    break;
+  case Mips::fixup_Mips_GOT16:
+    Type = ELF::R_MIPS_GOT16;
+    break;
+  case Mips::fixup_Mips_HI16:
+    Type = ELF::R_MIPS_HI16;
+    break;
+  case Mips::fixup_Mips_LO16:
+    Type = ELF::R_MIPS_LO16;
+    break;
+  case Mips::fixup_Mips_TLSGD:
+    Type = ELF::R_MIPS_TLS_GD;
+    break;
+  case Mips::fixup_Mips_GOTTPREL:
+    Type = ELF::R_MIPS_TLS_GOTTPREL;
+    break;
+  case Mips::fixup_Mips_TPREL_HI:
+    Type = ELF::R_MIPS_TLS_TPREL_HI16;
+    break;
+  case Mips::fixup_Mips_TPREL_LO:
+    Type = ELF::R_MIPS_TLS_TPREL_LO16;
+    break;
+  case Mips::fixup_Mips_Branch_PCRel:
+  case Mips::fixup_Mips_PC16:
+    Type = ELF::R_MIPS_PC16;
+    break;
+  }
+
+  return Type;
 }
+



From mcrosier at apple.com  Fri Nov  4 17:29:00 2011
From: mcrosier at apple.com (Chad Rosier)
Date: Fri, 04 Nov 2011 22:29:00 -0000
Subject: [llvm-commits] [llvm] r143739 -
	/llvm/trunk/lib/Target/ARM/ARMFastISel.cpp
Message-ID: <20111104222900.B18DD2A6C12C@llvm.org>

Author: mcrosier
Date: Fri Nov  4 17:29:00 2011
New Revision: 143739

URL: http://llvm.org/viewvc/llvm-project?rev=143739&view=rev
Log:
Enable support for materializing i1, i8, and i16 integers via move immediate.

Modified:
    llvm/trunk/lib/Target/ARM/ARMFastISel.cpp

Modified: llvm/trunk/lib/Target/ARM/ARMFastISel.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMFastISel.cpp?rev=143739&r1=143738&r2=143739&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMFastISel.cpp (original)
+++ llvm/trunk/lib/Target/ARM/ARMFastISel.cpp Fri Nov  4 17:29:00 2011
@@ -545,22 +545,27 @@
 
 unsigned ARMFastISel::ARMMaterializeInt(const Constant *C, EVT VT) {
 
-  // For now 32-bit only.
-  if (VT != MVT::i32) return false;
-
-  unsigned DestReg = createResultReg(TLI.getRegClassFor(VT));
+  if (VT != MVT::i32 && VT != MVT::i16 && VT != MVT::i8 && VT != MVT::i1)
+    return false;
 
   // If we can do this in a single instruction without a constant pool entry
   // do so now.
   const ConstantInt *CI = cast(C);
   if (Subtarget->hasV6T2Ops() && isUInt<16>(CI->getSExtValue())) {
     unsigned Opc = isThumb ? ARM::t2MOVi16 : ARM::MOVi16;
+    unsigned ImmReg = createResultReg(TLI.getRegClassFor(VT));
     AddOptionalDefs(BuildMI(*FuncInfo.MBB, FuncInfo.InsertPt, DL,
-                            TII.get(Opc), DestReg)
+                            TII.get(Opc), ImmReg)
                     .addImm(CI->getSExtValue()));
-    return DestReg;
+    return ImmReg;
   }
 
+  // For now 32-bit only.
+  if (VT != MVT::i32)
+    return false;
+
+  unsigned DestReg = createResultReg(TLI.getRegClassFor(VT));
+
   // MachineConstantPool wants an explicit alignment.
   unsigned Align = TD.getPrefTypeAlignment(C->getType());
   if (Align == 0) {



From daniel at zuster.org  Fri Nov  4 17:44:04 2011
From: daniel at zuster.org (Daniel Dunbar)
Date: Fri, 4 Nov 2011 15:44:04 -0700
Subject: [llvm-commits] [llvm] r143662 - /llvm/trunk/Makefile.rules
In-Reply-To: 
References: <20111103224622.08E1A2A6C12C@llvm.org>
	
Message-ID: 

Thanks for pointing this out Eli, I'll take a look.

Nakamura, do you own these bots? Is it possible for you to send me a
copy of the Makefile.llvmbuild file in the build directory?

I'll try and reproduce locally, but I have never set up an msys
environment on my Win32 box.

 - Daniel

On Fri, Nov 4, 2011 at 10:27 AM, Eli Friedman  wrote:
> On Thu, Nov 3, 2011 at 3:46 PM, Daniel Dunbar  wrote:
>> Author: ddunbar
>> Date: Thu Nov ?3 17:46:21 2011
>> New Revision: 143662
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=143662&view=rev
>> Log:
>> build/Make: Integrate llvm-build into Makefiles.
>> ?- Basically, we coordinate with llvm-build to create a Makefile fragment we can
>> ? easily use. For now, nothing is wired in except the support to automatically
>> ? regenerate this file when necessary.
>
> This appears to be breaking builds on some buildbots; see
> http://bb.pgr.jp/builders/clang-i686-msys
> http://lab.llvm.org:8011/builders/clang-native-mingw32-win7 .
>
> -Eli
>
>> Modified:
>> ? ?llvm/trunk/Makefile.rules
>>
>> Modified: llvm/trunk/Makefile.rules
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/Makefile.rules?rev=143662&r1=143661&r2=143662&view=diff
>> ==============================================================================
>> --- llvm/trunk/Makefile.rules (original)
>> +++ llvm/trunk/Makefile.rules Thu Nov ?3 17:46:21 2011
>> @@ -57,6 +57,54 @@
>>
>> ?$(UserTargets)::
>>
>> +#------------------------------------------------------------------------
>> +# LLVMBuild Integration
>> +#------------------------------------------------------------------------
>> +#
>> +# We use llvm-build to generate all the data required by the Makefile based
>> +# build system in one swoop:
>> +#
>> +# ?- We generate a file (a Makefile fragment) in the object root which contains
>> +# ? ?all the definitions that are required by Makefiles across the entire
>> +# ? ?project.
>> +#
>> +# ?- We generate the library table used by llvm-config.
>> +#
>> +# ?- We generate the dependencies for the Makefile fragment, so that we will
>> +# ? ?automatically reconfigure outselves.
>> +
>> +# The path to the llvm-build tool itself.
>> +LLVMBuildTool ?:= $(PROJ_SRC_ROOT)/utils/llvm-build/llvm-build
>> +
>> +# The files we are going to generate using llvm-build.
>> +LLVMBuildMakeFrag := $(PROJ_OBJ_ROOT)/Makefile.llvmbuild
>> +LLVMConfigLibraryDependenciesInc := \
>> + ? ? ? $(PROJ_OBJ_ROOT)/tools/llvm-config/LibraryDependencies.inc
>> +
>> +# The rule to create the LLVMBuild Makefile fragment as well as the llvm-config
>> +# library table.
>> +#
>> +# Note that this target gets its real dependencies generated for us by
>> +# llvm-build.
>> +$(LLVMBuildMakeFrag):
>> + ? ? ? $(EchoCmd) Constructing LLVMBuild project information. ; \
>> + ? ? ? $(LLVMBuildTool) \
>> + ? ? ? ? --write-library-table $(LLVMConfigLibraryDependenciesInc) \
>> + ? ? ? ? --write-make-fragment $(LLVMBuildMakeFrag)
>> +
>> +# Include the generated Makefile fragment.
>> +#
>> +# We currently only include the dependencies for the fragment itself if we are
>> +# at the top-level. Otherwise, recursive invocations would ends up doing
>> +# substantially more redundant stat'ing.
>> +#
>> +# This means that we won't properly regenerate things for developers used to
>> +# building from a subdirectory, but that is always somewhat unreliable.
>> +ifeq ($(LEVEL),.)
>> +LLVMBUILD_INCLUDE_DEPENDENCIES := 1
>> +endif
>> +-include $(LLVMBuildMakeFrag)
>> +
>> ?################################################################################
>> ?# PRECONDITIONS: that which must be built/checked first
>> ?################################################################################
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>


From rafael.espindola at gmail.com  Fri Nov  4 17:52:41 2011
From: rafael.espindola at gmail.com (=?UTF-8?Q?Rafael_Esp=C3=ADndola?=)
Date: Fri, 4 Nov 2011 18:52:41 -0400
Subject: [llvm-commits] [patch] More DW_AT_specification forward references
	fixes
Message-ID: 

This is a more general fix for pr11300. The test included in the patch
shows another path that can cause a subprogram die to be created
before its declaration. In this case, the definition is found when we
emit a DIE for a static local variable.

The patch fixes the problem by moving the check for a declaration to
CompileUnit::getOrCreateSubprogramDIE, which makes sure we cannot be
adding a definition before a declaration.

I am currently rebuilding firefox to see if this fixes all remaining
DW_AT_specification that point forward in the file. Is the patch OK if
it does?

Thanks,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: application/octet-stream
Size: 5370 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111104/1b2a0589/attachment.obj 

From daniel at zuster.org  Fri Nov  4 18:04:05 2011
From: daniel at zuster.org (Daniel Dunbar)
Date: Fri, 04 Nov 2011 23:04:05 -0000
Subject: [llvm-commits] [llvm] r143742 - in /llvm/trunk: CMakeLists.txt
	test/CMakeLists.txt
Message-ID: <20111104230405.866782A6C12C@llvm.org>

Author: ddunbar
Date: Fri Nov  4 18:04:05 2011
New Revision: 143742

URL: http://llvm.org/viewvc/llvm-project?rev=143742&view=rev
Log:
build/cmake: Change to require Python be available.

Modified:
    llvm/trunk/CMakeLists.txt
    llvm/trunk/test/CMakeLists.txt

Modified: llvm/trunk/CMakeLists.txt
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/CMakeLists.txt?rev=143742&r1=143741&r2=143742&view=diff
==============================================================================
--- llvm/trunk/CMakeLists.txt (original)
+++ llvm/trunk/CMakeLists.txt Fri Nov  4 18:04:05 2011
@@ -205,6 +205,15 @@
 include(config-ix)
 include(HandleLLVMOptions)
 
+# Verify that we can find a Python interpreter,
+include(FindPythonInterp)
+if( NOT PYTHONINTERP_FOUND )
+  message(FATAL_ERROR
+"Unable to find Python interpreter, required for builds and testing.
+
+Please install Python or specify the PYTHON_EXECUTABLE CMake variable.")
+endif()
+
 # Configure all of the various header file fragments LLVM uses which depend on
 # configuration variables.
 set(LLVM_ENUM_ASM_PRINTERS "")

Modified: llvm/trunk/test/CMakeLists.txt
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CMakeLists.txt?rev=143742&r1=143741&r2=143742&view=diff
==============================================================================
--- llvm/trunk/test/CMakeLists.txt (original)
+++ llvm/trunk/test/CMakeLists.txt Fri Nov  4 18:04:05 2011
@@ -24,62 +24,58 @@
   set(SHLIBPATH_VAR "LD_LIBRARY_PATH")
 endif()
 
-include(FindPythonInterp)
-if(PYTHONINTERP_FOUND)
-  set(LIT_ARGS "${LLVM_LIT_ARGS}")
-  separate_arguments(LIT_ARGS)
-
-  configure_file(
-    ${CMAKE_CURRENT_SOURCE_DIR}/site.exp.in
-    ${CMAKE_CURRENT_BINARY_DIR}/site.exp)
-
-  MAKE_DIRECTORY(${CMAKE_CURRENT_BINARY_DIR}/Unit)
-
-  # Configuration-time: See Unit/lit.site.cfg.in
-  set(LLVM_BUILD_MODE "%(build_mode)s")
-
-  set(LLVM_SOURCE_DIR ${LLVM_MAIN_SRC_DIR})
-  set(LLVM_BINARY_DIR ${LLVM_BINARY_DIR})
-  set(LLVM_TOOLS_DIR "${LLVM_TOOLS_BINARY_DIR}/%(build_config)s")
-  set(PYTHON_EXECUTABLE ${PYTHON_EXECUTABLE})
-  set(ENABLE_SHARED ${LLVM_SHARED_LIBS_ENABLED})
-  set(SHLIBPATH_VAR ${SHLIBPATH_VAR})
-
-  if(LLVM_ENABLE_ASSERTIONS AND NOT MSVC_IDE)
-    set(ENABLE_ASSERTIONS "1")
-  else()
-    set(ENABLE_ASSERTIONS "0")
-  endif()
-
-  configure_file(
-    ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
-    ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
-    @ONLY)
-  configure_file(
-    ${CMAKE_CURRENT_SOURCE_DIR}/Unit/lit.site.cfg.in
-    ${CMAKE_CURRENT_BINARY_DIR}/Unit/lit.site.cfg
-    @ONLY)
-
-  add_custom_target(check
-    COMMAND ${PYTHON_EXECUTABLE}
-                ${LLVM_SOURCE_DIR}/utils/lit/lit.py
-                --param llvm_site_config=${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
-                --param llvm_unit_site_config=${CMAKE_CURRENT_BINARY_DIR}/Unit/lit.site.cfg
-                --param build_config=${CMAKE_CFG_INTDIR}
-                --param build_mode=${RUNTIME_BUILD_MODE}
-                ${LIT_ARGS}
-                ${CMAKE_CURRENT_BINARY_DIR}
-                COMMENT "Running LLVM regression tests")
-  set_target_properties(check PROPERTIES FOLDER "Tests")
-
-  add_custom_target(check.deps)
-  add_dependencies(check check.deps)
-  add_dependencies(check.deps
-                UnitTests
-                BugpointPasses LLVMHello
-                llc lli llvm-ar llvm-as llvm-dis llvm-extract llvm-dwarfdump
-                llvm-ld llvm-link llvm-mc llvm-nm llvm-objdump macho-dump opt
-                FileCheck count not)
-  set_target_properties(check.deps PROPERTIES FOLDER "Tests")
+set(LIT_ARGS "${LLVM_LIT_ARGS}")
+separate_arguments(LIT_ARGS)
 
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/site.exp.in
+  ${CMAKE_CURRENT_BINARY_DIR}/site.exp)
+
+MAKE_DIRECTORY(${CMAKE_CURRENT_BINARY_DIR}/Unit)
+
+# Configuration-time: See Unit/lit.site.cfg.in
+set(LLVM_BUILD_MODE "%(build_mode)s")
+
+set(LLVM_SOURCE_DIR ${LLVM_MAIN_SRC_DIR})
+set(LLVM_BINARY_DIR ${LLVM_BINARY_DIR})
+set(LLVM_TOOLS_DIR "${LLVM_TOOLS_BINARY_DIR}/%(build_config)s")
+set(PYTHON_EXECUTABLE ${PYTHON_EXECUTABLE})
+set(ENABLE_SHARED ${LLVM_SHARED_LIBS_ENABLED})
+set(SHLIBPATH_VAR ${SHLIBPATH_VAR})
+
+if(LLVM_ENABLE_ASSERTIONS AND NOT MSVC_IDE)
+  set(ENABLE_ASSERTIONS "1")
+else()
+  set(ENABLE_ASSERTIONS "0")
 endif()
+
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
+  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
+  @ONLY)
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/Unit/lit.site.cfg.in
+  ${CMAKE_CURRENT_BINARY_DIR}/Unit/lit.site.cfg
+  @ONLY)
+
+add_custom_target(check
+  COMMAND ${PYTHON_EXECUTABLE}
+              ${LLVM_SOURCE_DIR}/utils/lit/lit.py
+              --param llvm_site_config=${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
+              --param llvm_unit_site_config=${CMAKE_CURRENT_BINARY_DIR}/Unit/lit.site.cfg
+              --param build_config=${CMAKE_CFG_INTDIR}
+              --param build_mode=${RUNTIME_BUILD_MODE}
+              ${LIT_ARGS}
+              ${CMAKE_CURRENT_BINARY_DIR}
+              COMMENT "Running LLVM regression tests")
+set_target_properties(check PROPERTIES FOLDER "Tests")
+
+add_custom_target(check.deps)
+add_dependencies(check check.deps)
+add_dependencies(check.deps
+              UnitTests
+              BugpointPasses LLVMHello
+              llc lli llvm-ar llvm-as llvm-dis llvm-extract llvm-dwarfdump
+              llvm-ld llvm-link llvm-mc llvm-nm llvm-objdump macho-dump opt
+              FileCheck count not)
+set_target_properties(check.deps PROPERTIES FOLDER "Tests")



From rafael.espindola at gmail.com  Fri Nov  4 18:10:39 2011
From: rafael.espindola at gmail.com (=?UTF-8?Q?Rafael_Esp=C3=ADndola?=)
Date: Fri, 4 Nov 2011 19:10:39 -0400
Subject: [llvm-commits] [patch] More DW_AT_specification forward
	references fixes
In-Reply-To: 
References: 
Message-ID: 

> I am currently rebuilding firefox to see if this fixes all remaining
> DW_AT_specification that point forward in the file. Is the patch OK if
> it does?

It fixes it. There are still other attributes to handle, but all
DW_AT_specification in firefox's XUL are backedges with this patch.

Cheers,
Rafael

From mcrosier at apple.com  Fri Nov  4 18:09:49 2011
From: mcrosier at apple.com (Chad Rosier)
Date: Fri, 04 Nov 2011 23:09:49 -0000
Subject: [llvm-commits] [llvm] r143743 -
	/llvm/trunk/lib/Target/ARM/ARMFastISel.cpp
Message-ID: <20111104230949.A0D262A6C12C@llvm.org>

Author: mcrosier
Date: Fri Nov  4 18:09:49 2011
New Revision: 143743

URL: http://llvm.org/viewvc/llvm-project?rev=143743&view=rev
Log:
When materializing an i32, SExt vs ZExt doesn't matter when we're trying to fit
in a 16-bit immediate.  However, for the shorter non-legal types (i.e., i1, i8,
i16) we should not sign-extend.  This prevents us from materializing things
such as 'true' (i.e., i1 1).

Modified:
    llvm/trunk/lib/Target/ARM/ARMFastISel.cpp

Modified: llvm/trunk/lib/Target/ARM/ARMFastISel.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMFastISel.cpp?rev=143743&r1=143742&r2=143743&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMFastISel.cpp (original)
+++ llvm/trunk/lib/Target/ARM/ARMFastISel.cpp Fri Nov  4 18:09:49 2011
@@ -551,7 +551,7 @@
   // If we can do this in a single instruction without a constant pool entry
   // do so now.
   const ConstantInt *CI = cast(C);
-  if (Subtarget->hasV6T2Ops() && isUInt<16>(CI->getSExtValue())) {
+  if (Subtarget->hasV6T2Ops() && isUInt<16>(CI->getZExtValue())) {
     unsigned Opc = isThumb ? ARM::t2MOVi16 : ARM::MOVi16;
     unsigned ImmReg = createResultReg(TLI.getRegClassFor(VT));
     AddOptionalDefs(BuildMI(*FuncInfo.MBB, FuncInfo.InsertPt, DL,



From daniel at zuster.org  Fri Nov  4 18:10:37 2011
From: daniel at zuster.org (Daniel Dunbar)
Date: Fri, 04 Nov 2011 23:10:37 -0000
Subject: [llvm-commits] [llvm] r143744 - in /llvm/trunk:
 docs/CommandGuide/llvm-build.pod utils/llvm-build/llvmbuild/main.py
Message-ID: <20111104231037.7CBCA2A6C12C@llvm.org>

Author: ddunbar
Date: Fri Nov  4 18:10:37 2011
New Revision: 143744

URL: http://llvm.org/viewvc/llvm-project?rev=143744&view=rev
Log:
llvm-build: Add initial --write-cmake-fragment option.

Modified:
    llvm/trunk/docs/CommandGuide/llvm-build.pod
    llvm/trunk/utils/llvm-build/llvmbuild/main.py

Modified: llvm/trunk/docs/CommandGuide/llvm-build.pod
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/CommandGuide/llvm-build.pod?rev=143744&r1=143743&r2=143744&view=diff
==============================================================================
--- llvm/trunk/docs/CommandGuide/llvm-build.pod (original)
+++ llvm/trunk/docs/CommandGuide/llvm-build.pod Fri Nov  4 18:10:37 2011
@@ -48,6 +48,13 @@
 Write out new I files based on the loaded components. This is
 useful for auto-upgrading the schema of the files.
 
+=item B<--write-cmake-fragment>
+
+Write out the LLVMBuild in the form of a CMake fragment, so it can easily be
+consumed by the CMake based build system. The exact contents and format of this
+file are closely tied to how LLVMBuild is integrated with CMake, see LLVM's
+top-level CMakeLists.txt.
+
 =item B<--write-make-fragment>
 
 Write out the LLVMBuild in the form of a Makefile fragment, so it can easily be

Modified: llvm/trunk/utils/llvm-build/llvmbuild/main.py
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/utils/llvm-build/llvmbuild/main.py?rev=143744&r1=143743&r2=143744&view=diff
==============================================================================
--- llvm/trunk/utils/llvm-build/llvmbuild/main.py (original)
+++ llvm/trunk/utils/llvm-build/llvmbuild/main.py Fri Nov  4 18:10:37 2011
@@ -286,22 +286,21 @@
         print >>f, '};'
         f.close()
 
-    def write_make_fragment(self, output_path):
+    def get_fragment_dependencies(self):
         """
-        write_make_fragment(output_path) -> None
+        get_fragment_dependencies() -> iter
 
-        Generate a Makefile fragment which includes all of the collated
-        LLVMBuild information in a format that is easily digestible by a
-        Makefile. The exact contents of this are closely tied to how the LLVM
-        Makefiles integrate LLVMBuild, see Makefile.rules in the top-level.
+        Compute the list of files (as absolute paths) on which the output
+        fragments depend (i.e., files for which a modification should trigger a
+        rebuild of the fragment).
         """
 
         # Construct a list of all the dependencies of the Makefile fragment
         # itself. These include all the LLVMBuild files themselves, as well as
         # all of our own sources.
-        dependencies = []
         for ci in self.component_infos:
-            dependencies.append(os.path.join(self.source_root, ci.subpath[1:]))
+            yield os.path.join(self.source_root, ci.subpath[1:],
+                               'LLVMBuild.txt')
 
         # Gather the list of necessary sources by just finding all loaded
         # modules that are inside the LLVM source tree.
@@ -320,7 +319,77 @@
             # If the path exists and is in the source tree, consider it a
             # dependency.
             if (path.startswith(self.source_root) and os.path.exists(path)):
-                dependencies.append(path)
+                yield path
+
+    def write_cmake_fragment(self, output_path):
+        """
+        write_cmake_fragment(output_path) -> None
+
+        Generate a CMake fragment which includes all of the collated LLVMBuild
+        information in a format that is easily digestible by a CMake. The exact
+        contents of this are closely tied to how the CMake configuration
+        integrates LLVMBuild, see CMakeLists.txt in the top-level.
+        """
+
+        dependencies = list(self.get_fragment_dependencies())
+
+        # Write out the CMake fragment.
+        f = open(output_path, 'w')
+
+        # Write the header.
+        header_fmt = '\
+#===-- %s - LLVMBuild Configuration for LLVM %s-*- CMake -*--===#'
+        header_name = os.path.basename(output_path)
+        header_pad = '-' * (80 - len(header_fmt % (header_name, '')))
+        header_string = header_fmt % (header_name, header_pad)
+        print >>f, """\
+%s
+#
+#                     The LLVM Compiler Infrastructure
+#
+# This file is distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
+#
+#===------------------------------------------------------------------------===#
+#
+# This file contains the LLVMBuild project information in a format easily
+# consumed by the CMake based build system.
+#
+# This file is autogenerated by llvm-build, do not edit!
+#
+#===------------------------------------------------------------------------===#
+""" % header_string
+
+        # Write the dependency information in the best way we can.
+        print >>f, """
+# LLVMBuild CMake fragment dependencies.
+#
+# CMake has no builtin way to declare that the configuration depends on
+# a particular file. However, a side effect of configure_file is to add
+# said input file to CMake's internal dependency list. So, we use that
+# and a dummy output file to communicate the dependency information to
+# CMake.
+#
+# FIXME: File a CMake RFE to get a properly supported version of this
+# feature."""
+        for dep in dependencies:
+            print >>f, """\
+configure_file(\"%s\"
+               ${CMAKE_CURRENT_BINARY_DIR}/DummyConfigureOutput)""" % (dep,)
+            
+        f.close()
+
+    def write_make_fragment(self, output_path):
+        """
+        write_make_fragment(output_path) -> None
+
+        Generate a Makefile fragment which includes all of the collated
+        LLVMBuild information in a format that is easily digestible by a
+        Makefile. The exact contents of this are closely tied to how the LLVM
+        Makefiles integrate LLVMBuild, see Makefile.rules in the top-level.
+        """
+
+        dependencies = list(self.get_fragment_dependencies())
 
         # Write out the Makefile fragment.
         f = open(output_path, 'w')
@@ -390,6 +459,10 @@
                       dest="write_library_table", metavar="PATH",
                       help="Write the C++ library dependency table to PATH",
                       action="store", default=None)
+    parser.add_option("", "--write-cmake-fragment",
+                      dest="write_cmake_fragment", metavar="PATH",
+                      help="Write the CMake project information to PATH",
+                      action="store", default=None)
     parser.add_option("", "--write-make-fragment",
                       dest="write_make_fragment", metavar="PATH",
                       help="Write the Makefile project information to PATH",
@@ -430,13 +503,17 @@
     if opts.write_llvmbuild:
         project_info.write_components(opts.write_llvmbuild)
 
-    # Write out the required librariy, if requested.
+    # Write out the required library table, if requested.
     if opts.write_library_table:
         project_info.write_library_table(opts.write_library_table)
 
-    # Write out the required librariy, if requested.
+    # Write out the make fragment, if requested.
     if opts.write_make_fragment:
         project_info.write_make_fragment(opts.write_make_fragment)
 
+    # Write out the cmake fragment, if requested.
+    if opts.write_cmake_fragment:
+        project_info.write_cmake_fragment(opts.write_cmake_fragment)
+
 if __name__=='__main__':
     main()



From dpatel at apple.com  Fri Nov  4 18:16:39 2011
From: dpatel at apple.com (Devang Patel)
Date: Fri, 04 Nov 2011 16:16:39 -0700
Subject: [llvm-commits] [patch] More DW_AT_specification
 forward	references fixes
In-Reply-To: 
References: 
	
Message-ID: <4C139C9E-9EF5-4AC3-B6E2-7F539C8B9627@apple.com>


On Nov 4, 2011, at 4:10 PM, Rafael Esp?ndola wrote:

>> I am currently rebuilding firefox to see if this fixes all remaining
>> DW_AT_specification that point forward in the file. Is the patch OK if
>> it does?
> 
> It fixes it. There are still other attributes to handle, but all
> DW_AT_specification in firefox's XUL are backedges with this patch.

Thanks for checking. LGTM.
-
Devang

From geek4civic at gmail.com  Fri Nov  4 18:19:19 2011
From: geek4civic at gmail.com (NAKAMURA Takumi)
Date: Sat, 5 Nov 2011 08:19:19 +0900
Subject: [llvm-commits] [llvm] r143662 - /llvm/trunk/Makefile.rules
In-Reply-To: 
References: <20111103224622.08E1A2A6C12C@llvm.org>
	
	
Message-ID: 

2011/11/5 Daniel Dunbar :
> Nakamura, do you own these bots? Is it possible for you to send me a
> copy of the Makefile.llvmbuild file in the build directory?

Here is. It is made by generic Python/w32.

...Takumi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.llvmbuild
Type: application/octet-stream
Size: 16167 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111105/e14f579a/attachment.obj 

From gkistanova at gmail.com  Fri Nov  4 18:29:49 2011
From: gkistanova at gmail.com (Galina Kistanova)
Date: Fri, 4 Nov 2011 16:29:49 -0700
Subject: [llvm-commits] [llvm] r143662 - /llvm/trunk/Makefile.rules
In-Reply-To: 
References: <20111103224622.08E1A2A6C12C@llvm.org>
	
	
Message-ID: 

Windows builders clang-native-mingw32-win7, llvm-gcc-native-mingw32,
llvm-gcc-native-mingw32-win7 also fail:
http://lab.llvm.org:8011/builders/llvm-gcc-native-mingw32/builds/239/steps/run.build.step.make_llvm/logs/stdio


Thanks

Galina



On Fri, Nov 4, 2011 at 3:44 PM, Daniel Dunbar  wrote:
> Thanks for pointing this out Eli, I'll take a look.
>
> Nakamura, do you own these bots? Is it possible for you to send me a
> copy of the Makefile.llvmbuild file in the build directory?
>
> I'll try and reproduce locally, but I have never set up an msys
> environment on my Win32 box.
>
> ?- Daniel
>
> On Fri, Nov 4, 2011 at 10:27 AM, Eli Friedman  wrote:
>> On Thu, Nov 3, 2011 at 3:46 PM, Daniel Dunbar  wrote:
>>> Author: ddunbar
>>> Date: Thu Nov ?3 17:46:21 2011
>>> New Revision: 143662
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=143662&view=rev
>>> Log:
>>> build/Make: Integrate llvm-build into Makefiles.
>>> ?- Basically, we coordinate with llvm-build to create a Makefile fragment we can
>>> ? easily use. For now, nothing is wired in except the support to automatically
>>> ? regenerate this file when necessary.
>>
>> This appears to be breaking builds on some buildbots; see
>> http://bb.pgr.jp/builders/clang-i686-msys
>> http://lab.llvm.org:8011/builders/clang-native-mingw32-win7 .
>>
>> -Eli
>>
>>> Modified:
>>> ? ?llvm/trunk/Makefile.rules
>>>
>>> Modified: llvm/trunk/Makefile.rules
>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/Makefile.rules?rev=143662&r1=143661&r2=143662&view=diff
>>> ==============================================================================
>>> --- llvm/trunk/Makefile.rules (original)
>>> +++ llvm/trunk/Makefile.rules Thu Nov ?3 17:46:21 2011
>>> @@ -57,6 +57,54 @@
>>>
>>> ?$(UserTargets)::
>>>
>>> +#------------------------------------------------------------------------
>>> +# LLVMBuild Integration
>>> +#------------------------------------------------------------------------
>>> +#
>>> +# We use llvm-build to generate all the data required by the Makefile based
>>> +# build system in one swoop:
>>> +#
>>> +# ?- We generate a file (a Makefile fragment) in the object root which contains
>>> +# ? ?all the definitions that are required by Makefiles across the entire
>>> +# ? ?project.
>>> +#
>>> +# ?- We generate the library table used by llvm-config.
>>> +#
>>> +# ?- We generate the dependencies for the Makefile fragment, so that we will
>>> +# ? ?automatically reconfigure outselves.
>>> +
>>> +# The path to the llvm-build tool itself.
>>> +LLVMBuildTool ?:= $(PROJ_SRC_ROOT)/utils/llvm-build/llvm-build
>>> +
>>> +# The files we are going to generate using llvm-build.
>>> +LLVMBuildMakeFrag := $(PROJ_OBJ_ROOT)/Makefile.llvmbuild
>>> +LLVMConfigLibraryDependenciesInc := \
>>> + ? ? ? $(PROJ_OBJ_ROOT)/tools/llvm-config/LibraryDependencies.inc
>>> +
>>> +# The rule to create the LLVMBuild Makefile fragment as well as the llvm-config
>>> +# library table.
>>> +#
>>> +# Note that this target gets its real dependencies generated for us by
>>> +# llvm-build.
>>> +$(LLVMBuildMakeFrag):
>>> + ? ? ? $(EchoCmd) Constructing LLVMBuild project information. ; \
>>> + ? ? ? $(LLVMBuildTool) \
>>> + ? ? ? ? --write-library-table $(LLVMConfigLibraryDependenciesInc) \
>>> + ? ? ? ? --write-make-fragment $(LLVMBuildMakeFrag)
>>> +
>>> +# Include the generated Makefile fragment.
>>> +#
>>> +# We currently only include the dependencies for the fragment itself if we are
>>> +# at the top-level. Otherwise, recursive invocations would ends up doing
>>> +# substantially more redundant stat'ing.
>>> +#
>>> +# This means that we won't properly regenerate things for developers used to
>>> +# building from a subdirectory, but that is always somewhat unreliable.
>>> +ifeq ($(LEVEL),.)
>>> +LLVMBUILD_INCLUDE_DEPENDENCIES := 1
>>> +endif
>>> +-include $(LLVMBuildMakeFrag)
>>> +
>>> ?################################################################################
>>> ?# PRECONDITIONS: that which must be built/checked first
>>> ?################################################################################
>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>
>>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>


From lhames at gmail.com  Fri Nov  4 18:30:04 2011
From: lhames at gmail.com (Lang Hames)
Date: Fri, 4 Nov 2011 16:30:04 -0700
Subject: [llvm-commits] [PATCH] Smarter unaligned stores of constant values.
Message-ID: 

Encountered the following when I tried outputting an unaligned store of -1
on ARM:

_foo:                                   @ @foo
@ BB#0:                                 @ %entry
        mov     r1, #255
        mov     r2, #255
        strb    r1, [r0, #3]
        orr     r1, r2, #65280
        strb    r1, [r0, #2]
        mvn     r1, #-16777216
        strb    r1, [r0, #1]
        mvn     r1, #0
        strb    r1, [r0]
        mov     pc, lr

The strange constants are coming out of the legalizer, which tries to
legalize the unaligned store by repeatedly splitting it into two half-sized
stores, and shifting the constant around. This results in several new and
confusing constants being introduced.

This patch checks for constant value stores, and if the two halves of the
constant have the same bit-pattern it avoids creating new constants.

Could someone who's more familiar with the legalizer take a look and let me
know if this is Ok to commit?  (I'm also planning to enable unaligned
stores on supported subtargets, but that's a different issue)

Cheers,
Lang.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111104/8902373f/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: legalizer.patch
Type: application/octet-stream
Size: 2104 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111104/8902373f/attachment.obj 

From lhames at gmail.com  Fri Nov  4 18:33:29 2011
From: lhames at gmail.com (Lang Hames)
Date: Fri, 4 Nov 2011 16:33:29 -0700
Subject: [llvm-commits] [PATCH] Smarter unaligned stores of constant
	values.
In-Reply-To: 
References: 
Message-ID: 

Postscript: Output with patch is exactly what you'd expect:

_foo:                                   @ @foo
@ BB#0:                                 @ %entry
        mvn     r1, #0
        strb    r1, [r0, #3]
        strb    r1, [r0, #2]
        strb    r1, [r0, #1]
        strb    r1, [r0]
        mov     pc, lr

Cheers,
Lang.

On Fri, Nov 4, 2011 at 4:30 PM, Lang Hames  wrote:

> Encountered the following when I tried outputting an unaligned store of -1
> on ARM:
>
> _foo:                                   @ @foo
> @ BB#0:                                 @ %entry
>         mov     r1, #255
>         mov     r2, #255
>         strb    r1, [r0, #3]
>         orr     r1, r2, #65280
>         strb    r1, [r0, #2]
>         mvn     r1, #-16777216
>         strb    r1, [r0, #1]
>         mvn     r1, #0
>         strb    r1, [r0]
>         mov     pc, lr
>
> The strange constants are coming out of the legalizer, which tries to
> legalize the unaligned store by repeatedly splitting it into two half-sized
> stores, and shifting the constant around. This results in several new and
> confusing constants being introduced.
>
> This patch checks for constant value stores, and if the two halves of the
> constant have the same bit-pattern it avoids creating new constants.
>
> Could someone who's more familiar with the legalizer take a look and let
> me know if this is Ok to commit?  (I'm also planning to enable unaligned
> stores on supported subtargets, but that's a different issue)
>
> Cheers,
> Lang.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111104/1f59633e/attachment.html 

From eli.friedman at gmail.com  Fri Nov  4 18:41:32 2011
From: eli.friedman at gmail.com (Eli Friedman)
Date: Fri, 4 Nov 2011 16:41:32 -0700
Subject: [llvm-commits] [PATCH] Smarter unaligned stores of constant
	values.
In-Reply-To: 
References: 
Message-ID: 

On Fri, Nov 4, 2011 at 4:30 PM, Lang Hames  wrote:
> Encountered the following when I tried outputting an unaligned store of -1
> on ARM:
> _foo: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ @foo
> @ BB#0: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? @ %entry
> ? ? ? ? mov ? ? r1, #255
> ? ? ? ? mov ? ? r2, #255
> ? ? ? ? strb ? ?r1, [r0, #3]
> ? ? ? ? orr ? ? r1, r2, #65280
> ? ? ? ? strb ? ?r1, [r0, #2]
> ? ? ? ? mvn ? ? r1, #-16777216
> ? ? ? ? strb ? ?r1, [r0, #1]
> ? ? ? ? mvn ? ? r1, #0
> ? ? ? ? strb ? ?r1, [r0]
> ? ? ? ? mov ? ? pc, lr
> The strange constants are coming out of the legalizer, which tries to
> legalize the unaligned store by repeatedly splitting it into two half-sized
> stores, and shifting the constant around. This results in several new and
> confusing constants being introduced.
> This patch checks for constant value stores, and if the two halves of the
> constant have the same bit-pattern it avoids creating new constants.
> Could someone who's more familiar with the legalizer take a look and let me
> know if this is Ok to commit? ?(I'm also planning to enable unaligned stores
> on supported subtargets, but that's a different issue)

TargetLowering::SimplifyDemandedBits should be able to take care of
this; if it can't, it should be fixed.

-Eli


From daniel at zuster.org  Fri Nov  4 18:40:11 2011
From: daniel at zuster.org (Daniel Dunbar)
Date: Fri, 04 Nov 2011 23:40:11 -0000
Subject: [llvm-commits] [llvm] r143745 -
	/llvm/trunk/utils/llvm-build/llvmbuild/main.py
Message-ID: <20111104234011.DB9672A6C12C@llvm.org>

Author: ddunbar
Date: Fri Nov  4 18:40:11 2011
New Revision: 143745

URL: http://llvm.org/viewvc/llvm-project?rev=143745&view=rev
Log:
llvm-build: Quote colons in target names, in an attempt to make msys happy.

Modified:
    llvm/trunk/utils/llvm-build/llvmbuild/main.py

Modified: llvm/trunk/utils/llvm-build/llvmbuild/main.py
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/utils/llvm-build/llvmbuild/main.py?rev=143745&r1=143744&r2=143745&view=diff
==============================================================================
--- llvm/trunk/utils/llvm-build/llvmbuild/main.py (original)
+++ llvm/trunk/utils/llvm-build/llvmbuild/main.py Fri Nov  4 18:40:11 2011
@@ -7,6 +7,19 @@
 
 ###
 
+def mk_quote_string_for_target(value):
+    """
+    mk_quote_string_for_target(target_name) -> str
+
+    Return a quoted form of the given target_name suitable for including in a 
+    Makefile as a target name.
+    """
+
+    # The only quoting we currently perform is for ':', to support msys users.
+    return value.replace(":", "\\:")
+
+###
+
 class LLVMProjectInfo(object):
     @staticmethod
     def load_infos_from_path(llvmbuild_source_root):
@@ -427,7 +440,7 @@
 # performance of recursive Make systems.""" 
         print >>f, 'ifeq ($(LLVMBUILD_INCLUDE_DEPENDENCIES),1)'
         print >>f, "# The dependencies for this Makefile fragment itself."
-        print >>f, "%s: \\" % (output_path,)
+        print >>f, "%s: \\" % (mk_quote_string_for_target(output_path),)
         for dep in dependencies:
             print >>f, "\t%s \\" % (dep,)
         print >>f
@@ -438,7 +451,7 @@
 # The dummy targets to allow proper regeneration even when files are moved or
 # removed."""
         for dep in dependencies:
-            print >>f, "%s:" % (dep,)
+            print >>f, "%s:" % (mk_quote_string_for_target(dep),)
         print >>f, 'endif'
 
         f.close()



From daniel at zuster.org  Fri Nov  4 18:40:14 2011
From: daniel at zuster.org (Daniel Dunbar)
Date: Fri, 04 Nov 2011 23:40:14 -0000
Subject: [llvm-commits] [llvm] r143746 - /llvm/trunk/Makefile.rules
Message-ID: <20111104234014.CE1942A6C12C@llvm.org>

Author: ddunbar
Date: Fri Nov  4 18:40:14 2011
New Revision: 143746

URL: http://llvm.org/viewvc/llvm-project?rev=143746&view=rev
Log:
build/make: Fix the output path of the llvm-config-2 library dependency table.

Modified:
    llvm/trunk/Makefile.rules

Modified: llvm/trunk/Makefile.rules
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/Makefile.rules?rev=143746&r1=143745&r2=143746&view=diff
==============================================================================
--- llvm/trunk/Makefile.rules (original)
+++ llvm/trunk/Makefile.rules Fri Nov  4 18:40:14 2011
@@ -79,7 +79,7 @@
 # The files we are going to generate using llvm-build.
 LLVMBuildMakeFrag := $(PROJ_OBJ_ROOT)/Makefile.llvmbuild
 LLVMConfigLibraryDependenciesInc := \
-	$(PROJ_OBJ_ROOT)/tools/llvm-config/LibraryDependencies.inc
+	$(PROJ_OBJ_ROOT)/tools/llvm-config-2/LibraryDependencies.inc
 
 # The rule to create the LLVMBuild Makefile fragment as well as the llvm-config
 # library table.



From mcrosier at apple.com  Fri Nov  4 18:45:39 2011
From: mcrosier at apple.com (Chad Rosier)
Date: Fri, 04 Nov 2011 23:45:39 -0000
Subject: [llvm-commits] [llvm] r143749 -
	/llvm/trunk/lib/Target/ARM/ARMFastISel.cpp
Message-ID: <20111104234539.E9F1F2A6C12C@llvm.org>

Author: mcrosier
Date: Fri Nov  4 18:45:39 2011
New Revision: 143749

URL: http://llvm.org/viewvc/llvm-project?rev=143749&view=rev
Log:
Cannot create a result register for non-legal types.

Modified:
    llvm/trunk/lib/Target/ARM/ARMFastISel.cpp

Modified: llvm/trunk/lib/Target/ARM/ARMFastISel.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMFastISel.cpp?rev=143749&r1=143748&r2=143749&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMFastISel.cpp (original)
+++ llvm/trunk/lib/Target/ARM/ARMFastISel.cpp Fri Nov  4 18:45:39 2011
@@ -552,8 +552,9 @@
   // do so now.
   const ConstantInt *CI = cast(C);
   if (Subtarget->hasV6T2Ops() && isUInt<16>(CI->getZExtValue())) {
+    EVT SrcVT = MVT::i32;
     unsigned Opc = isThumb ? ARM::t2MOVi16 : ARM::MOVi16;
-    unsigned ImmReg = createResultReg(TLI.getRegClassFor(VT));
+    unsigned ImmReg = createResultReg(TLI.getRegClassFor(SrcVT));
     AddOptionalDefs(BuildMI(*FuncInfo.MBB, FuncInfo.InsertPt, DL,
                             TII.get(Opc), ImmReg)
                     .addImm(CI->getSExtValue()));



From eli.friedman at gmail.com  Fri Nov  4 18:46:11 2011
From: eli.friedman at gmail.com (Eli Friedman)
Date: Fri, 04 Nov 2011 23:46:11 -0000
Subject: [llvm-commits] [llvm] r143750 - in /llvm/trunk:
 lib/Target/X86/X86VZeroUpper.cpp test/CodeGen/X86/avx-vzeroupper.ll
Message-ID: <20111104234612.08C762A6C12C@llvm.org>

Author: efriedma
Date: Fri Nov  4 18:46:11 2011
New Revision: 143750

URL: http://llvm.org/viewvc/llvm-project?rev=143750&view=rev
Log:
Enhanced vzeroupper insertion pass that avoids inserting vzeroupper where it is unnecessary through local analysis.  Patch from Bruno Cardoso Lopes, with some additional changes.

I'm going to wait for any review comments and perform some additional testing before turning this on by default.


Modified:
    llvm/trunk/lib/Target/X86/X86VZeroUpper.cpp
    llvm/trunk/test/CodeGen/X86/avx-vzeroupper.ll

Modified: llvm/trunk/lib/Target/X86/X86VZeroUpper.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86VZeroUpper.cpp?rev=143750&r1=143749&r2=143750&view=diff
==============================================================================
--- llvm/trunk/lib/Target/X86/X86VZeroUpper.cpp (original)
+++ llvm/trunk/lib/Target/X86/X86VZeroUpper.cpp Fri Nov  4 18:46:11 2011
@@ -14,14 +14,16 @@
 //
 //===----------------------------------------------------------------------===//
 
-#define DEBUG_TYPE "x86-codegen"
+#define DEBUG_TYPE "x86-vzeroupper"
 #include "X86.h"
 #include "X86InstrInfo.h"
 #include "llvm/ADT/Statistic.h"
 #include "llvm/CodeGen/MachineFunctionPass.h"
 #include "llvm/CodeGen/MachineInstrBuilder.h"
+#include "llvm/CodeGen/MachineRegisterInfo.h"
 #include "llvm/CodeGen/Passes.h"
-#include "llvm/GlobalValue.h"
+#include "llvm/Support/Debug.h"
+#include "llvm/Support/raw_ostream.h"
 #include "llvm/Target/TargetInstrInfo.h"
 using namespace llvm;
 
@@ -41,6 +43,60 @@
   private:
     const TargetInstrInfo *TII; // Machine instruction info.
     MachineBasicBlock *MBB;     // Current basic block
+
+    // Any YMM register live-in to this function?
+    bool FnHasLiveInYmm;
+
+    // BBState - Contains the state of each MBB: unknown, clean, dirty
+    SmallVector BBState;
+
+    // BBSolved - Keep track of all MBB which had been already analyzed
+    // and there is no further processing required.
+    BitVector BBSolved;
+
+    // Machine Basic Blocks are classified according this pass:
+    //
+    //  ST_UNKNOWN - The MBB state is unknown, meaning from the entry state
+    //    until the MBB exit there isn't a instruction using YMM to change
+    //    the state to dirty, or one of the incoming predecessors is unknown
+    //    and there's not a dirty predecessor between them.
+    //
+    //  ST_CLEAN - No YMM usage in the end of the MBB. A MBB could have
+    //    instructions using YMM and be marked ST_CLEAN, as long as the state
+    //    is cleaned by a vzeroupper before any call.
+    //
+    //  ST_DIRTY - Any MBB ending with a YMM usage not cleaned up by a
+    //    vzeroupper instruction.
+    //
+    //  ST_INIT - Placeholder for an empty state set
+    //
+    enum {
+      ST_UNKNOWN = 0,
+      ST_CLEAN   = 1,
+      ST_DIRTY   = 2,
+      ST_INIT    = 3
+    };
+
+    // computeState - Given two states, compute the resulting state, in
+    // the following way
+    //
+    //  1) One dirty state yields another dirty state
+    //  2) All states must be clean for the result to be clean
+    //  3) If none above and one unknown, the result state is also unknown
+    //
+    unsigned computeState(unsigned PrevState, unsigned CurState) {
+      if (PrevState == ST_INIT)
+        return CurState;
+
+      if (PrevState == ST_DIRTY || CurState == ST_DIRTY)
+        return ST_DIRTY;
+
+      if (PrevState == ST_CLEAN && CurState == ST_CLEAN)
+        return ST_CLEAN;
+
+      return ST_UNKNOWN;
+    }
+
   };
   char VZeroUpperInserter::ID = 0;
 }
@@ -49,57 +105,181 @@
   return new VZeroUpperInserter();
 }
 
-/// runOnMachineFunction - Loop over all of the basic blocks, inserting
-/// vzero upper instructions before function calls.
-bool VZeroUpperInserter::runOnMachineFunction(MachineFunction &MF) {
-  TII = MF.getTarget().getInstrInfo();
-  bool Changed = false;
-
-  // Process any unreachable blocks in arbitrary order now.
-  for (MachineFunction::iterator BB = MF.begin(), E = MF.end(); BB != E; ++BB)
-    Changed |= processBasicBlock(MF, *BB);
+static bool isYmmReg(unsigned Reg) {
+  if (Reg >= X86::YMM0 && Reg <= X86::YMM15)
+    return true;
 
-  return Changed;
+  return false;
 }
 
-static bool isCallToModuleFn(const MachineInstr *MI) {
-  assert(MI->getDesc().isCall() && "Isn't a call instruction");
+static bool checkFnHasLiveInYmm(MachineRegisterInfo &MRI) {
+  for (MachineRegisterInfo::livein_iterator I = MRI.livein_begin(),
+       E = MRI.livein_end(); I != E; ++I)
+    if (isYmmReg(I->first))
+      return true;
 
+  return false;
+}
+
+static bool hasYmmReg(MachineInstr *MI) {
   for (int i = 0, e = MI->getNumOperands(); i != e; ++i) {
     const MachineOperand &MO = MI->getOperand(i);
-
-    if (!MO.isGlobal())
+    if (!MO.isReg())
       continue;
-
-    const GlobalValue *GV = MO.getGlobal();
-    GlobalValue::LinkageTypes LT = GV->getLinkage();
-    if (GV->isInternalLinkage(LT) || GV->isPrivateLinkage(LT) ||
-        (GV->isExternalLinkage(LT) && !GV->isDeclaration()))
+    if (MO.isDebug())
+      continue;
+    if (isYmmReg(MO.getReg()))
       return true;
-
-    return false;
   }
   return false;
 }
 
+/// runOnMachineFunction - Loop over all of the basic blocks, inserting
+/// vzero upper instructions before function calls.
+bool VZeroUpperInserter::runOnMachineFunction(MachineFunction &MF) {
+  TII = MF.getTarget().getInstrInfo();
+  MachineRegisterInfo &MRI = MF.getRegInfo();
+  bool EverMadeChange = false;
+
+  // Fast check: if the function doesn't use any ymm registers, we don't need
+  // to insert any VZEROUPPER instructions.  This is constant-time, so it is
+  // cheap in the common case of no ymm use.
+  bool YMMUsed = false;
+  TargetRegisterClass *RC = X86::VR256RegisterClass;
+  for (TargetRegisterClass::iterator i = RC->begin(), e = RC->end();
+       i != e; i++) {
+    if (MRI.isPhysRegUsed(*i)) {
+      YMMUsed = true;
+      break;
+    }
+  }
+  if (!YMMUsed)
+    return EverMadeChange;
+
+  // Pre-compute the existence of any live-in YMM registers to this function
+  FnHasLiveInYmm = checkFnHasLiveInYmm(MRI);
+
+  assert(BBState.empty());
+  BBState.resize(MF.getNumBlockIDs(), 0);
+  BBSolved.resize(MF.getNumBlockIDs(), 0);
+
+  // Each BB state depends on all predecessors, loop over until everything
+  // converges.  (Once we converge, we can implicitly mark everything that is
+  // still ST_UNKNOWN as ST_CLEAN.)
+  while (1) {
+    bool MadeChange = false;
+
+    // Process all basic blocks.
+    for (MachineFunction::iterator I = MF.begin(), E = MF.end(); I != E; ++I)
+      MadeChange |= processBasicBlock(MF, *I);
+
+    // If this iteration over the code changed anything, keep iterating.
+    if (!MadeChange) break;
+    EverMadeChange = true;
+  }
+
+  BBState.clear();
+  BBSolved.clear();
+  return EverMadeChange;
+}
+
 /// processBasicBlock - Loop over all of the instructions in the basic block,
 /// inserting vzero upper instructions before function calls.
 bool VZeroUpperInserter::processBasicBlock(MachineFunction &MF,
                                            MachineBasicBlock &BB) {
   bool Changed = false;
+  unsigned BBNum = BB.getNumber();
   MBB = &BB;
 
+  // Don't process already solved BBs
+  if (BBSolved[BBNum])
+    return false; // No changes
+
+  // Check the state of all predecessors
+  unsigned EntryState = ST_INIT;
+  for (MachineBasicBlock::const_pred_iterator PI = BB.pred_begin(),
+       PE = BB.pred_end(); PI != PE; ++PI) {
+    EntryState = computeState(EntryState, BBState[(*PI)->getNumber()]);
+    if (EntryState == ST_DIRTY)
+      break;
+  }
+
+
+  // The entry MBB for the function may set the inital state to dirty if
+  // the function receives any YMM incoming arguments
+  if (MBB == MF.begin()) {
+    EntryState = ST_CLEAN;
+    if (FnHasLiveInYmm)
+      EntryState = ST_DIRTY;
+  }
+
+  // The current state is initialized according to the predecessors
+  unsigned CurState = EntryState;
+  bool BBHasCall = false;
+
   for (MachineBasicBlock::iterator I = BB.begin(); I != BB.end(); ++I) {
     MachineInstr *MI = I;
     DebugLoc dl = I->getDebugLoc();
+    bool isControlFlow = MI->getDesc().isCall() || MI->getDesc().isReturn();
+
+    // Shortcut: don't need to check regular instructions in dirty state. 
+    if (!isControlFlow && CurState == ST_DIRTY)
+      continue;
 
-    // Insert a vzeroupper instruction before each control transfer
-    // to functions outside this module
-    if (MI->getDesc().isCall() && !isCallToModuleFn(MI)) {
-      BuildMI(*MBB, I, dl, TII->get(X86::VZEROUPPER));
-      ++NumVZU;
+    if (hasYmmReg(MI)) {
+      // We found a ymm-using instruction; this could be an AVX instruction,
+      // or it could be control flow.
+      CurState = ST_DIRTY;
+      continue;
+    }
+
+    // Check for control-flow out of the current function (which might
+    // indirectly execute SSE instructions).
+    if (!isControlFlow)
+      continue;
+
+    BBHasCall = true;
+
+    // The VZEROUPPER instruction resets the upper 128 bits of all Intel AVX
+    // registers. This instruction has zero latency. In addition, the processor
+    // changes back to Clean state, after which execution of Intel SSE
+    // instructions or Intel AVX instructions has no transition penalty. Add
+    // the VZEROUPPER instruction before any function call/return that might
+    // execute SSE code.
+    // FIXME: In some cases, we may want to move the VZEROUPPER into a
+    // predecessor block.
+    if (CurState == ST_DIRTY) {
+      // Only insert the VZEROUPPER in case the entry state isn't unknown.
+      // When unknown, only compute the information within the block to have
+      // it available in the exit if possible, but don't change the block.
+      if (EntryState != ST_UNKNOWN) {
+        BuildMI(*MBB, I, dl, TII->get(X86::VZEROUPPER));
+        ++NumVZU;
+      }
+
+      // After the inserted VZEROUPPER the state becomes clean again, but
+      // other YMM may appear before other subsequent calls or even before
+      // the end of the BB.
+      CurState = ST_CLEAN;
     }
   }
 
+  DEBUG(dbgs() << "MBB #" << BBNum
+               << ", current state: " << CurState << '\n');
+
+  // A BB can only be considered solved when we both have done all the
+  // necessary transformations, and have computed the exit state.  This happens
+  // in two cases:
+  //  1) We know the entry state: this immediately implies the exit state and
+  //     all the necessary transformations.
+  //  2) There are no calls, and and a non-call instruction marks this block:
+  //     no transformations are necessary, and we know the exit state.
+  if (EntryState != ST_UNKNOWN || (!BBHasCall && CurState != ST_UNKNOWN))
+    BBSolved[BBNum] = true;
+
+  if (CurState != BBState[BBNum])
+    Changed = true;
+
+  BBState[BBNum] = CurState;
   return Changed;
 }

Modified: llvm/trunk/test/CodeGen/X86/avx-vzeroupper.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/avx-vzeroupper.ll?rev=143750&r1=143749&r2=143750&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/X86/avx-vzeroupper.ll (original)
+++ llvm/trunk/test/CodeGen/X86/avx-vzeroupper.ll Fri Nov  4 18:46:11 2011
@@ -1,26 +1,83 @@
 ; RUN: llc < %s -x86-use-vzeroupper -mtriple=x86_64-apple-darwin -mcpu=corei7-avx -mattr=+avx | FileCheck %s
 
-define <4 x float> @do_sse_local(<4 x float> %a) nounwind uwtable readnone ssp {
-entry:
-  %add.i = fadd <4 x float> %a, %a
-  ret <4 x float> %add.i
-}
+declare <4 x float> @do_sse(<4 x float>)
+declare <8 x float> @do_avx(<8 x float>)
+declare <4 x float> @llvm.x86.avx.vextractf128.ps.256(<8 x float>, i8) nounwind readnone
+ at x = common global <4 x float> zeroinitializer, align 16
+ at g = common global <8 x float> zeroinitializer, align 32
+
+;; Basic checking - don't emit any vzeroupper instruction
 
 ; CHECK: _test00
 define <4 x float> @test00(<4 x float> %a, <4 x float> %b) nounwind uwtable ssp {
 entry:
+  ; CHECK-NOT: vzeroupper
   %add.i = fadd <4 x float> %a, %b
+  %call3 = call <4 x float> @do_sse(<4 x float> %add.i) nounwind
+  ; CHECK: ret
+  ret <4 x float> %call3
+}
+
+;; Check parameter 256-bit parameter passing
+
+; CHECK: _test01
+define <8 x float> @test01(<4 x float> %a, <4 x float> %b, <8 x float> %c) nounwind uwtable ssp {
+entry:
+  %tmp = load <4 x float>* @x, align 16
   ; CHECK: vzeroupper
   ; CHECK-NEXT: callq _do_sse
-  %call3 = tail call <4 x float> @do_sse(<4 x float> %add.i) nounwind
-  %sub.i = fsub <4 x float> %call3, %add.i
+  %call = tail call <4 x float> @do_sse(<4 x float> %tmp) nounwind
+  store <4 x float> %call, <4 x float>* @x, align 16
   ; CHECK-NOT: vzeroupper
-  ; CHECK: callq _do_sse_local
-  %call8 = tail call <4 x float> @do_sse_local(<4 x float> %sub.i)
+  ; CHECK: callq _do_sse
+  %call2 = tail call <4 x float> @do_sse(<4 x float> %call) nounwind
+  store <4 x float> %call2, <4 x float>* @x, align 16
+  ; CHECK: ret
+  ret <8 x float> %c
+}
+
+;; Test the pass convergence and also that vzeroupper is only issued when necessary,
+;; for this function it should be only once
+
+; CHECK: _test02
+define <4 x float> @test02(<4 x float> %a, <4 x float> %b) nounwind uwtable ssp {
+entry:
+  %add.i = fadd <4 x float> %a, %b
+  br label %for.body
+
+for.body:                                         ; preds = %for.body, %entry
+  ; CHECK: LBB
+  ; CHECK-NOT: vzeroupper
+  %i.018 = phi i32 [ 0, %entry ], [ %1, %for.body ]
+  %c.017 = phi <4 x float> [ %add.i, %entry ], [ %call14, %for.body ]
+  ; CHECK: callq _do_sse
+  %call5 = tail call <4 x float> @do_sse(<4 x float> %c.017) nounwind
+  ; CHECK-NEXT: callq _do_sse
+  %call7 = tail call <4 x float> @do_sse(<4 x float> %call5) nounwind
+  %tmp11 = load <8 x float>* @g, align 32
+  %0 = tail call <4 x float> @llvm.x86.avx.vextractf128.ps.256(<8 x float> %tmp11, i8 1) nounwind
   ; CHECK: vzeroupper
-  ; CHECK-NEXT: jmp _do_sse
-  %call10 = tail call <4 x float> @do_sse(<4 x float> %call8) nounwind
-  ret <4 x float> %call10
+  ; CHECK-NEXT: callq _do_sse
+  %call14 = tail call <4 x float> @do_sse(<4 x float> %0) nounwind
+  %1 = add nsw i32 %i.018, 1
+  %exitcond = icmp eq i32 %1, 4
+  br i1 %exitcond, label %for.end, label %for.body
+
+for.end:                                          ; preds = %for.body
+  ret <4 x float> %call14
 }
 
-declare <4 x float> @do_sse(<4 x float>)
+;; Check that we also perform vzeroupper when we return from a function.
+
+; CHECK: _test03
+define <4 x float> @test03(<4 x float> %a, <4 x float> %b) nounwind uwtable ssp {
+entry:
+  %shuf = shufflevector <4 x float> %a, <4 x float> %b, <8 x i32> 
+  ; CHECK-NOT: vzeroupper
+  ; CHECK: call
+  %call = call <8 x float> @do_avx(<8 x float> %shuf) nounwind
+  %shuf2 = shufflevector <8 x float> %call, <8 x float> undef, <4 x i32> 
+  ; CHECK: vzeroupper
+  ; CHECK: ret
+  ret <4 x float> %shuf2
+}



From peter_cooper at apple.com  Fri Nov  4 18:49:15 2011
From: peter_cooper at apple.com (Pete Cooper)
Date: Fri, 04 Nov 2011 23:49:15 -0000
Subject: [llvm-commits] [llvm] r143753 -
	/llvm/trunk/lib/CodeGen/IfConversion.cpp
Message-ID: <20111104234915.183A72A6C12C@llvm.org>

Author: pete
Date: Fri Nov  4 18:49:14 2011
New Revision: 143753

URL: http://llvm.org/viewvc/llvm-project?rev=143753&view=rev
Log:
Added missing &.  Fixes 

Modified:
    llvm/trunk/lib/CodeGen/IfConversion.cpp

Modified: llvm/trunk/lib/CodeGen/IfConversion.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/IfConversion.cpp?rev=143753&r1=143752&r2=143753&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/IfConversion.cpp (original)
+++ llvm/trunk/lib/CodeGen/IfConversion.cpp Fri Nov  4 18:49:14 2011
@@ -1319,7 +1319,7 @@
   // fold the tail block in as well. Otherwise, unless it falls through to the
   // tail, add a unconditional branch to it.
   if (TailBB) {
-    BBInfo TailBBI = BBAnalysis[TailBB->getNumber()];
+    BBInfo &TailBBI = BBAnalysis[TailBB->getNumber()];
     bool CanMergeTail = !TailBBI.HasFallThrough;
     // There may still be a fall-through edge from BBI1 or BBI2 to TailBB;
     // check if there are any other predecessors besides those.



From evan.cheng at apple.com  Fri Nov  4 18:55:06 2011
From: evan.cheng at apple.com (Evan Cheng)
Date: Fri, 04 Nov 2011 16:55:06 -0700
Subject: [llvm-commits] [llvm] r143753 -
 /llvm/trunk/lib/CodeGen/IfConversion.cpp
In-Reply-To: <20111104234915.183A72A6C12C@llvm.org>
References: <20111104234915.183A72A6C12C@llvm.org>
Message-ID: <4AFBFB5D-AB18-464C-AAEB-3987ADB8E7CF@apple.com>

Thanks. Is it possible to add a reduced test case?

Evan

On Nov 4, 2011, at 4:49 PM, Pete Cooper wrote:

> Author: pete
> Date: Fri Nov  4 18:49:14 2011
> New Revision: 143753
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=143753&view=rev
> Log:
> Added missing &.  Fixes 
> 
> Modified:
>    llvm/trunk/lib/CodeGen/IfConversion.cpp
> 
> Modified: llvm/trunk/lib/CodeGen/IfConversion.cpp
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/IfConversion.cpp?rev=143753&r1=143752&r2=143753&view=diff
> ==============================================================================
> --- llvm/trunk/lib/CodeGen/IfConversion.cpp (original)
> +++ llvm/trunk/lib/CodeGen/IfConversion.cpp Fri Nov  4 18:49:14 2011
> @@ -1319,7 +1319,7 @@
>   // fold the tail block in as well. Otherwise, unless it falls through to the
>   // tail, add a unconditional branch to it.
>   if (TailBB) {
> -    BBInfo TailBBI = BBAnalysis[TailBB->getNumber()];
> +    BBInfo &TailBBI = BBAnalysis[TailBB->getNumber()];
>     bool CanMergeTail = !TailBBI.HasFallThrough;
>     // There may still be a fall-through edge from BBI1 or BBI2 to TailBB;
>     // check if there are any other predecessors besides those.
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits


From peter_cooper at apple.com  Fri Nov  4 18:55:45 2011
From: peter_cooper at apple.com (Peter Cooper)
Date: Fri, 04 Nov 2011 16:55:45 -0700
Subject: [llvm-commits] [llvm] r143753 -
 /llvm/trunk/lib/CodeGen/IfConversion.cpp
In-Reply-To: <4AFBFB5D-AB18-464C-AAEB-3987ADB8E7CF@apple.com>
References: <20111104234915.183A72A6C12C@llvm.org>
	<4AFBFB5D-AB18-464C-AAEB-3987ADB8E7CF@apple.com>
Message-ID: 

Hope so.  Just trying to come up with one now

Pete

On Nov 4, 2011, at 4:55 PM, Evan Cheng wrote:

> Thanks. Is it possible to add a reduced test case?
> 
> Evan
> 
> On Nov 4, 2011, at 4:49 PM, Pete Cooper wrote:
> 
>> Author: pete
>> Date: Fri Nov  4 18:49:14 2011
>> New Revision: 143753
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=143753&view=rev
>> Log:
>> Added missing &.  Fixes 
>> 
>> Modified:
>>   llvm/trunk/lib/CodeGen/IfConversion.cpp
>> 
>> Modified: llvm/trunk/lib/CodeGen/IfConversion.cpp
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/IfConversion.cpp?rev=143753&r1=143752&r2=143753&view=diff
>> ==============================================================================
>> --- llvm/trunk/lib/CodeGen/IfConversion.cpp (original)
>> +++ llvm/trunk/lib/CodeGen/IfConversion.cpp Fri Nov  4 18:49:14 2011
>> @@ -1319,7 +1319,7 @@
>>  // fold the tail block in as well. Otherwise, unless it falls through to the
>>  // tail, add a unconditional branch to it.
>>  if (TailBB) {
>> -    BBInfo TailBBI = BBAnalysis[TailBB->getNumber()];
>> +    BBInfo &TailBBI = BBAnalysis[TailBB->getNumber()];
>>    bool CanMergeTail = !TailBBI.HasFallThrough;
>>    // There may still be a fall-through edge from BBI1 or BBI2 to TailBB;
>>    // check if there are any other predecessors besides those.
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 


From lhames at gmail.com  Fri Nov  4 18:58:45 2011
From: lhames at gmail.com (Lang Hames)
Date: Fri, 4 Nov 2011 16:58:45 -0700
Subject: [llvm-commits] [PATCH] Smarter unaligned stores of constant
	values.
In-Reply-To: 
References: 
	
Message-ID: 

Thanks Eli! Looking into SimplifyDemandedBits now...

Cheers,
Lang.

On Fri, Nov 4, 2011 at 4:41 PM, Eli Friedman  wrote:

> On Fri, Nov 4, 2011 at 4:30 PM, Lang Hames  wrote:
> > Encountered the following when I tried outputting an unaligned store of
> -1
> > on ARM:
> > _foo:                                   @ @foo
> > @ BB#0:                                 @ %entry
> >         mov     r1, #255
> >         mov     r2, #255
> >         strb    r1, [r0, #3]
> >         orr     r1, r2, #65280
> >         strb    r1, [r0, #2]
> >         mvn     r1, #-16777216
> >         strb    r1, [r0, #1]
> >         mvn     r1, #0
> >         strb    r1, [r0]
> >         mov     pc, lr
> > The strange constants are coming out of the legalizer, which tries to
> > legalize the unaligned store by repeatedly splitting it into two
> half-sized
> > stores, and shifting the constant around. This results in several new and
> > confusing constants being introduced.
> > This patch checks for constant value stores, and if the two halves of the
> > constant have the same bit-pattern it avoids creating new constants.
> > Could someone who's more familiar with the legalizer take a look and let
> me
> > know if this is Ok to commit?  (I'm also planning to enable unaligned
> stores
> > on supported subtargets, but that's a different issue)
>
> TargetLowering::SimplifyDemandedBits should be able to take care of
> this; if it can't, it should be fixed.
>
> -Eli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111104/4bf71477/attachment.html 

From mcrosier at apple.com  Fri Nov  4 19:02:56 2011
From: mcrosier at apple.com (Chad Rosier)
Date: Sat, 05 Nov 2011 00:02:56 -0000
Subject: [llvm-commits] [llvm] r143755 -
	/llvm/trunk/lib/Target/ARM/ARMCallingConv.td
Message-ID: <20111105000256.ABADD2A6C12C@llvm.org>

Author: mcrosier
Date: Fri Nov  4 19:02:56 2011
New Revision: 143755

URL: http://llvm.org/viewvc/llvm-project?rev=143755&view=rev
Log:
Allow i1 to be promoted to i32 for ARM APCS calling convention.

Modified:
    llvm/trunk/lib/Target/ARM/ARMCallingConv.td

Modified: llvm/trunk/lib/Target/ARM/ARMCallingConv.td
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMCallingConv.td?rev=143755&r1=143754&r2=143755&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMCallingConv.td (original)
+++ llvm/trunk/lib/Target/ARM/ARMCallingConv.td Fri Nov  4 19:02:56 2011
@@ -25,7 +25,7 @@
   // Handles byval parameters.
   CCIfByVal>,
     
-  CCIfType<[i8, i16], CCPromoteToType>,
+  CCIfType<[i1, i8, i16], CCPromoteToType>,
 
   // Handle all vector types as either f64 or v2f64.
   CCIfType<[v1i64, v2i32, v4i16, v8i8, v2f32], CCBitConvertToType>,



From echristo at apple.com  Fri Nov  4 19:41:16 2011
From: echristo at apple.com (Eric Christopher)
Date: Fri, 04 Nov 2011 17:41:16 -0700
Subject: [llvm-commits] [llvm] r143749 -
 /llvm/trunk/lib/Target/ARM/ARMFastISel.cpp
In-Reply-To: <20111104234539.E9F1F2A6C12C@llvm.org>
References: <20111104234539.E9F1F2A6C12C@llvm.org>
Message-ID: <67A3D530-8A2D-4022-9BE2-2344EE0ED5F5@apple.com>


On Nov 4, 2011, at 4:45 PM, Chad Rosier wrote:

> +    EVT SrcVT = MVT::i32;
>     unsigned Opc = isThumb ? ARM::t2MOVi16 : ARM::MOVi16;
> -    unsigned ImmReg = createResultReg(TLI.getRegClassFor(VT));
> +    unsigned ImmReg = createResultReg(TLI.getRegClassFor(SrcVT));

There's a lot of code that uses this construct as well:

TargetRegisterClass *RC = isThumb?ARM::rGPRRegisterClass
                                        		    :ARM::GPRRegisterClass;

Yours is likely shorter if we wanted to change all of them :)

-eric


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111104/ef658493/attachment.html 

From daniel at zuster.org  Fri Nov  4 23:07:44 2011
From: daniel at zuster.org (Daniel Dunbar)
Date: Sat, 05 Nov 2011 04:07:44 -0000
Subject: [llvm-commits] [llvm] r143781 -
	/llvm/trunk/utils/llvm-build/llvmbuild/main.py
Message-ID: <20111105040744.3CFAA2A6C12C@llvm.org>

Author: ddunbar
Date: Fri Nov  4 23:07:43 2011
New Revision: 143781

URL: http://llvm.org/viewvc/llvm-project?rev=143781&view=rev
Log:
utils/llvm-build: Add trivial quoting of slashes for CMake fragment.

Modified:
    llvm/trunk/utils/llvm-build/llvmbuild/main.py

Modified: llvm/trunk/utils/llvm-build/llvmbuild/main.py
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/utils/llvm-build/llvmbuild/main.py?rev=143781&r1=143780&r2=143781&view=diff
==============================================================================
--- llvm/trunk/utils/llvm-build/llvmbuild/main.py (original)
+++ llvm/trunk/utils/llvm-build/llvmbuild/main.py Fri Nov  4 23:07:43 2011
@@ -7,6 +7,19 @@
 
 ###
 
+def cmake_quote_string(value):
+    """
+    cmake_quote_string(value) -> str
+
+    Return a quoted form of the given value that is suitable for use in CMake
+    language files.
+    """
+
+    # Currently, we only handle escaping backslashes.
+    value = value.replace("\\", "\\\\")
+
+    return value
+
 def mk_quote_string_for_target(value):
     """
     mk_quote_string_for_target(target_name) -> str
@@ -388,8 +401,9 @@
         for dep in dependencies:
             print >>f, """\
 configure_file(\"%s\"
-               ${CMAKE_CURRENT_BINARY_DIR}/DummyConfigureOutput)""" % (dep,)
-            
+               ${CMAKE_CURRENT_BINARY_DIR}/DummyConfigureOutput)""" % (
+                cmake_quote_string(dep),)
+
         f.close()
 
     def write_make_fragment(self, output_path):



From daniel at zuster.org  Fri Nov  4 23:07:49 2011
From: daniel at zuster.org (Daniel Dunbar)
Date: Sat, 05 Nov 2011 04:07:49 -0000
Subject: [llvm-commits] [llvm] r143782 -
	/llvm/trunk/utils/llvm-build/llvmbuild/main.py
Message-ID: <20111105040749.481B02A6C12C@llvm.org>

Author: ddunbar
Date: Fri Nov  4 23:07:49 2011
New Revision: 143782

URL: http://llvm.org/viewvc/llvm-project?rev=143782&view=rev
Log:
utils/llvm-build: Ensure output directory exists for tools which write various fragments.

Modified:
    llvm/trunk/utils/llvm-build/llvmbuild/main.py

Modified: llvm/trunk/utils/llvm-build/llvmbuild/main.py
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/utils/llvm-build/llvmbuild/main.py?rev=143782&r1=143781&r2=143782&view=diff
==============================================================================
--- llvm/trunk/utils/llvm-build/llvmbuild/main.py (original)
+++ llvm/trunk/utils/llvm-build/llvmbuild/main.py Fri Nov  4 23:07:49 2011
@@ -31,6 +31,17 @@
     # The only quoting we currently perform is for ':', to support msys users.
     return value.replace(":", "\\:")
 
+def make_install_dir(path):
+    """
+    make_install_dir(path) -> None
+
+    Create the given directory path for installation, including any parents.
+    """
+
+    # os.makedirs considers it an error to be called with an existant path.
+    if not os.path.exists(path):
+        os.makedirs(path)
+
 ###
 
 class LLVMProjectInfo(object):
@@ -276,6 +287,7 @@
                                      for _,_,deps in entries) + 1
 
         # Write out the library table.
+        make_install_dir(os.path.dirname(output_path))
         f = open(output_path, 'w')
         print >>f, """\
 //===- llvm-build generated file --------------------------------*- C++ -*-===//
@@ -360,6 +372,7 @@
         dependencies = list(self.get_fragment_dependencies())
 
         # Write out the CMake fragment.
+        make_install_dir(os.path.dirname(output_path))
         f = open(output_path, 'w')
 
         # Write the header.
@@ -419,6 +432,7 @@
         dependencies = list(self.get_fragment_dependencies())
 
         # Write out the Makefile fragment.
+        make_install_dir(os.path.dirname(output_path))
         f = open(output_path, 'w')
 
         # Write the header.



From peter at pcc.me.uk  Fri Nov  4 23:17:20 2011
From: peter at pcc.me.uk (Peter Collingbourne)
Date: Sat, 05 Nov 2011 04:17:20 -0000
Subject: [llvm-commits] [llvm] r143783 -
	/llvm/trunk/tools/gold/CMakeLists.txt
Message-ID: <20111105041721.020B32A6C12C@llvm.org>

Author: pcc
Date: Fri Nov  4 23:17:20 2011
New Revision: 143783

URL: http://llvm.org/viewvc/llvm-project?rev=143783&view=rev
Log:
Use absolute path to exportsfile in gold plugin CMake build.

(Ninja generator requirement.)

Modified:
    llvm/trunk/tools/gold/CMakeLists.txt

Modified: llvm/trunk/tools/gold/CMakeLists.txt
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/gold/CMakeLists.txt?rev=143783&r1=143782&r2=143783&view=diff
==============================================================================
--- llvm/trunk/tools/gold/CMakeLists.txt (original)
+++ llvm/trunk/tools/gold/CMakeLists.txt Fri Nov  4 23:17:20 2011
@@ -40,6 +40,7 @@
   set_property(SOURCE gold-plugin.cpp APPEND PROPERTY
     OBJECT_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/exportsfile)
 
-  target_link_libraries(LLVMgold LTO -Wl,--version-script,exportsfile)
+  target_link_libraries(LLVMgold LTO
+                   -Wl,--version-script,${CMAKE_CURRENT_BINARY_DIR}/exportsfile)
   add_dependencies(LLVMgold gold_exports)
 endif()



From peter at pcc.me.uk  Fri Nov  4 23:17:25 2011
From: peter at pcc.me.uk (Peter Collingbourne)
Date: Sat, 05 Nov 2011 04:17:25 -0000
Subject: [llvm-commits] [llvm] r143784 -
	/llvm/trunk/tools/lto/LTOCodeGenerator.cpp
Message-ID: <20111105041725.89C8F2A6C12C@llvm.org>

Author: pcc
Date: Fri Nov  4 23:17:25 2011
New Revision: 143784

URL: http://llvm.org/viewvc/llvm-project?rev=143784&view=rev
Log:
Now that the linker supports lazily materialising globals, don't
materialise them in LTO.

I observed a ~0.5-1% speedup for an LTO link of opt.

Modified:
    llvm/trunk/tools/lto/LTOCodeGenerator.cpp

Modified: llvm/trunk/tools/lto/LTOCodeGenerator.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/lto/LTOCodeGenerator.cpp?rev=143784&r1=143783&r2=143784&view=diff
==============================================================================
--- llvm/trunk/tools/lto/LTOCodeGenerator.cpp (original)
+++ llvm/trunk/tools/lto/LTOCodeGenerator.cpp Fri Nov  4 23:17:25 2011
@@ -90,10 +90,6 @@
 
 bool LTOCodeGenerator::addModule(LTOModule* mod, std::string& errMsg)
 {
-
-  if(mod->getLLVVMModule()->MaterializeAllPermanently(&errMsg))
-    return true;
-
   bool ret = _linker.LinkInModule(mod->getLLVVMModule(), &errMsg);
 
   const std::vector &undefs = mod->getAsmUndefinedRefs();



From peter at pcc.me.uk  Fri Nov  4 23:17:28 2011
From: peter at pcc.me.uk (Peter Collingbourne)
Date: Sat, 05 Nov 2011 04:17:28 -0000
Subject: [llvm-commits] [llvm] r143785 - /llvm/trunk/docs/GoldPlugin.html
Message-ID: <20111105041729.061522A6C12C@llvm.org>

Author: pcc
Date: Fri Nov  4 23:17:28 2011
New Revision: 143785

URL: http://llvm.org/viewvc/llvm-project?rev=143785&view=rev
Log:
Recommend the -flto flag instead of -use-gold-plugin, and update
other aspects of the gold plugin docs to reflect reality.

Modified:
    llvm/trunk/docs/GoldPlugin.html

Modified: llvm/trunk/docs/GoldPlugin.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/GoldPlugin.html?rev=143785&r1=143784&r2=143785&view=diff
==============================================================================
--- llvm/trunk/docs/GoldPlugin.html (original)
+++ llvm/trunk/docs/GoldPlugin.html Fri Nov  4 23:17:28 2011
@@ -89,11 +89,11 @@
   -emit-llvm or -flto, or the -O4 flag which is
   synonymous with -O3 -flto.
 
-  Clang has a -use-gold-plugin option which looks for the
-  gold plugin in the same directories as it looks for cc1 and passes
-  the -plugin option to ld. It will not look for an alternate
-  linker, which is why you need gold to be the installed system linker in your
-  path.
+  Any of these flags will also cause clang to look for the
+  gold plugin in the lib directory under its prefix and pass the
+  -plugin option to ld. It will not look for an alternate
+  linker, which is why you need gold to be the installed system linker in
+  your path.
 
   If you want ar and nm to work seamlessly as well, install
   LLVMgold.so to /usr/lib/bfd-plugins. If you built your
@@ -141,10 +141,10 @@
 }
 
 --- command lines ---
-$ clang -flto a.c -c -o a.o                 # <-- a.o is LLVM bitcode file
-$ ar q a.a a.o                              # <-- a.a is an archive with LLVM bitcode
-$ clang b.c -c -o b.o                       # <-- b.o is native object file
-$ clang -use-gold-plugin a.a b.o -o main    # <-- link with LLVMgold plugin
+$ clang -flto a.c -c -o a.o      # <-- a.o is LLVM bitcode file
+$ ar q a.a a.o                   # <-- a.a is an archive with LLVM bitcode
+$ clang b.c -c -o b.o            # <-- b.o is native object file
+$ clang -flto a.a b.o -o main    # <-- link with LLVMgold plugin
 
$PREFIX
Release/lib/LLVMgold.so
$PREFIX/libexec/gcc/x86_64-unknown-linux-gnu/4.2.1/
$PREFIX/lib/bfd-plugins/
$PREFIX
-export CC="$PREFIX/bin/clang -use-gold-plugin"
-export CXX="$PREFIX/bin/clang++ -use-gold-plugin"
+export CC="$PREFIX/bin/clang -flto"
+export CXX="$PREFIX/bin/clang++ -flto"
 export AR="$PREFIX/bin/ar"
 export NM="$PREFIX/bin/nm"
 export RANLIB=/bin/true #ranlib is not needed, and doesn't support .bc files in .a
@@ -187,8 +186,8 @@
      Or you can just set your path:
  export PATH="$PREFIX/bin:$PATH"
-export CC="clang -use-gold-plugin"
-export CXX="clang++ -use-gold-plugin"
+export CC="clang -flto"
+export CXX="clang++ -flto"
 export RANLIB=/bin/true
 export CFLAGS="-O4"
 



From daniel at zuster.org  Sat Nov  5 01:30:03 2011
From: daniel at zuster.org (Daniel Dunbar)
Date: Sat, 05 Nov 2011 06:30:03 -0000
Subject: [llvm-commits] [llvm] r143793 - /llvm/trunk/CMakeLists.txt
Message-ID: <20111105063004.01E052A6C12C@llvm.org>

Author: ddunbar
Date: Sat Nov  5 01:30:03 2011
New Revision: 143793

URL: http://llvm.org/viewvc/llvm-project?rev=143793&view=rev
Log:
build/cmake: Enable initial llvm-build integration.
 - Generates the llvm-config-2 LibraryDependencies.inc file.
 - Generates dependency information so that cmake will automatically reconfigure
   when LLVMBuild.txt files are changed.

Modified:
    llvm/trunk/CMakeLists.txt

Modified: llvm/trunk/CMakeLists.txt
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/CMakeLists.txt?rev=143793&r1=143792&r2=143793&view=diff
==============================================================================
--- llvm/trunk/CMakeLists.txt (original)
+++ llvm/trunk/CMakeLists.txt Sat Nov  5 01:30:03 2011
@@ -214,6 +214,54 @@
 Please install Python or specify the PYTHON_EXECUTABLE CMake variable.")
 endif()
 
+######
+# LLVMBuild Integration
+#
+# We use llvm-build to generate all the data required by the CMake based
+# build system in one swoop:
+#
+#  - We generate a file (a CMake fragment) in the object root which contains
+#    all the definitions that are required by CMake.
+#
+#  - We generate the library table used by llvm-config.
+#
+#  - We generate the dependencies for the CMake fragment, so that we will
+#    automatically reconfigure outselves.
+
+set(LLVMBUILDTOOL "${LLVM_MAIN_SRC_DIR}/utils/llvm-build/llvm-build")
+set(LLVMCONFIGLIBRARYDEPENDENCIESINC
+  "${LLVM_BINARY_DIR}/tools/llvm-config-2/LibraryDependencies.inc")
+set(LLVMBUILDCMAKEFRAG
+  "${LLVM_BINARY_DIR}/LLVMBuild.cmake")
+message(STATUS "Constructing LLVMBuild project information")
+execute_process(
+  COMMAND ${PYTHON_EXECUTABLE} ${LLVMBUILDTOOL}
+            --write-library-table ${LLVMCONFIGLIBRARYDEPENDENCIESINC}
+            --write-cmake-fragment ${LLVMBUILDCMAKEFRAG}
+            ERROR_VARIABLE LLVMBUILDOUTPUT
+            ERROR_VARIABLE LLVMBUILDERRORS
+            OUTPUT_STRIP_TRAILING_WHITESPACE
+            ERROR_STRIP_TRAILING_WHITESPACE
+  RESULT_VARIABLE LLVMBUILDRESULT)
+
+# On Win32, CMake doesn't properly handle piping the default output/error
+# streams into the GUI console. So, we explicitly catch and report them.
+if( NOT "${LLVMBUILDOUTPUT}" STREQUAL "")
+  message(STATUS "llvm-build output: ${LLVMBUILDOUTPUT}")
+endif()
+if( NOT "${LLVMBUILDRESULT}" STREQUAL "0" )
+  message(FATAL_ERROR
+    "Unexpected failure executing llvm-build: ${LLVMBUILDERRORS}")
+endif()
+
+# Include the generated CMake fragment. This will define properties from the
+# LLVMBuild files in a format which is easy to consume from CMake, and will add
+# the dependencies so that CMake will reconfigure properly when the LLVMBuild
+# files change.
+include(${LLVMBUILDCMAKEFRAG})
+
+######
+
 # Configure all of the various header file fragments LLVM uses which depend on
 # configuration variables.
 set(LLVM_ENUM_ASM_PRINTERS "")



From benny.kra at googlemail.com  Sat Nov  5 03:57:41 2011
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Sat, 05 Nov 2011 08:57:41 -0000
Subject: [llvm-commits] [llvm] r143799 - in /llvm/trunk:
 include/llvm/Support/DataTypes.h.cmake include/llvm/Support/DataTypes.h.in
 lib/CodeGen/AsmPrinter/AsmPrinter.cpp lib/CodeGen/AsmPrinter/DIE.cpp
 lib/DebugInfo/DWARFDebugArangeSet.cpp lib/DebugInfo/DWARFDebugAranges.cpp
 lib/DebugInfo/DWARFDebugLine.cpp lib/DebugInfo/DWARFFormValue.cpp
 lib/Support/Timer.cpp lib/Target/X86/InstPrinter/X86ATTInstPrinter.cpp
 tools/llvm-objdump/MachODump.cpp tools/llvm-size/llvm-size.cpp
Message-ID: <20111105085741.50BB02A6C12C@llvm.org>

Author: d0k
Date: Sat Nov  5 03:57:40 2011
New Revision: 143799

URL: http://llvm.org/viewvc/llvm-project?rev=143799&view=rev
Log:
Add more PRI.64 macros for MSVC and use them throughout the codebase.

Modified:
    llvm/trunk/include/llvm/Support/DataTypes.h.cmake
    llvm/trunk/include/llvm/Support/DataTypes.h.in
    llvm/trunk/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
    llvm/trunk/lib/CodeGen/AsmPrinter/DIE.cpp
    llvm/trunk/lib/DebugInfo/DWARFDebugArangeSet.cpp
    llvm/trunk/lib/DebugInfo/DWARFDebugAranges.cpp
    llvm/trunk/lib/DebugInfo/DWARFDebugLine.cpp
    llvm/trunk/lib/DebugInfo/DWARFFormValue.cpp
    llvm/trunk/lib/Support/Timer.cpp
    llvm/trunk/lib/Target/X86/InstPrinter/X86ATTInstPrinter.cpp
    llvm/trunk/tools/llvm-objdump/MachODump.cpp
    llvm/trunk/tools/llvm-size/llvm-size.cpp

Modified: llvm/trunk/include/llvm/Support/DataTypes.h.cmake
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/DataTypes.h.cmake?rev=143799&r1=143798&r2=143799&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Support/DataTypes.h.cmake (original)
+++ llvm/trunk/include/llvm/Support/DataTypes.h.cmake Sat Nov  5 03:57:40 2011
@@ -167,9 +167,24 @@
 # define UINT64_C(C) C##ui64
 #endif
 
+#ifndef PRId64
+# define PRId64 "I64d"
+#endif
+#ifndef PRIi64
+# define PRIu64 "I64i"
+#endif
+#ifndef PRIo64
+# define PRIx64 "I64o"
+#endif
+#ifndef PRIu64
+# define PRIu64 "I64u"
+#endif
 #ifndef PRIx64
 # define PRIx64 "I64x"
 #endif
+#ifndef PRIX64
+# define PRIX64 "I64X"
+#endif
 
 #endif /* _MSC_VER */
 

Modified: llvm/trunk/include/llvm/Support/DataTypes.h.in
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/DataTypes.h.in?rev=143799&r1=143798&r2=143799&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Support/DataTypes.h.in (original)
+++ llvm/trunk/include/llvm/Support/DataTypes.h.in Sat Nov  5 03:57:40 2011
@@ -167,9 +167,24 @@
 # define UINT64_C(C) C##ui64
 #endif
 
+#ifndef PRId64
+# define PRId64 "I64d"
+#endif
+#ifndef PRIi64
+# define PRIu64 "I64i"
+#endif
+#ifndef PRIo64
+# define PRIx64 "I64o"
+#endif
+#ifndef PRIu64
+# define PRIu64 "I64u"
+#endif
 #ifndef PRIx64
 # define PRIx64 "I64x"
 #endif
+#ifndef PRIX64
+# define PRIX64 "I64X"
+#endif
 
 #endif /* _MSC_VER */
 

Modified: llvm/trunk/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/AsmPrinter/AsmPrinter.cpp?rev=143799&r1=143798&r2=143799&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/AsmPrinter/AsmPrinter.cpp (original)
+++ llvm/trunk/lib/CodeGen/AsmPrinter/AsmPrinter.cpp Sat Nov  5 03:57:40 2011
@@ -1759,7 +1759,8 @@
     case 4:
     case 8:
       if (AP.isVerbose())
-        AP.OutStreamer.GetCommentOS() << format("0x%llx\n", CI->getZExtValue());
+        AP.OutStreamer.GetCommentOS() << format("0x%" PRIx64 "\n",
+                                                CI->getZExtValue());
       AP.OutStreamer.EmitIntValue(CI->getZExtValue(), Size, AddrSpace);
       return;
     default:

Modified: llvm/trunk/lib/CodeGen/AsmPrinter/DIE.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/AsmPrinter/DIE.cpp?rev=143799&r1=143798&r2=143799&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/AsmPrinter/DIE.cpp (original)
+++ llvm/trunk/lib/CodeGen/AsmPrinter/DIE.cpp Sat Nov  5 03:57:40 2011
@@ -230,8 +230,8 @@
 
 #ifndef NDEBUG
 void DIEInteger::print(raw_ostream &O) {
-  O << "Int: " << (int64_t)Integer
-    << format("  0x%llx", (unsigned long long)Integer);
+  O << "Int: " << (int64_t)Integer << "  0x";
+  O.write_hex(Integer);
 }
 #endif
 

Modified: llvm/trunk/lib/DebugInfo/DWARFDebugArangeSet.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/DebugInfo/DWARFDebugArangeSet.cpp?rev=143799&r1=143798&r2=143799&view=diff
==============================================================================
--- llvm/trunk/lib/DebugInfo/DWARFDebugArangeSet.cpp (original)
+++ llvm/trunk/lib/DebugInfo/DWARFDebugArangeSet.cpp Sat Nov  5 03:57:40 2011
@@ -122,8 +122,9 @@
   const uint32_t hex_width = Header.AddrSize * 2;
   for (DescriptorConstIter pos = ArangeDescriptors.begin(),
        end = ArangeDescriptors.end(); pos != end; ++pos)
-    OS << format("[0x%*.*llx -", hex_width, hex_width, pos->Address)
-       << format(" 0x%*.*llx)\n", hex_width, hex_width, pos->getEndAddress());
+    OS << format("[0x%*.*" PRIx64 " -", hex_width, hex_width, pos->Address)
+       << format(" 0x%*.*" PRIx64 ")\n",
+                 hex_width, hex_width, pos->getEndAddress());
 }
 
 

Modified: llvm/trunk/lib/DebugInfo/DWARFDebugAranges.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/DebugInfo/DWARFDebugAranges.cpp?rev=143799&r1=143798&r2=143799&view=diff
==============================================================================
--- llvm/trunk/lib/DebugInfo/DWARFDebugAranges.cpp (original)
+++ llvm/trunk/lib/DebugInfo/DWARFDebugAranges.cpp Sat Nov  5 03:57:40 2011
@@ -100,13 +100,14 @@
   const uint32_t num_ranges = getNumRanges();
   for (uint32_t i = 0; i < num_ranges; ++i) {
     const Range &range = Aranges[i];
-    OS << format("0x%8.8x: [0x%8.8llx - 0x%8.8llx)\n", range.Offset,
-                 (uint64_t)range.LoPC, (uint64_t)range.HiPC());
+    OS << format("0x%8.8x: [0x%8.8" PRIx64 " - 0x%8.8" PRIx64 ")\n",
+                 range.Offset, (uint64_t)range.LoPC, (uint64_t)range.HiPC());
   }
 }
 
 void DWARFDebugAranges::Range::dump(raw_ostream &OS) const {
-  OS << format("{0x%8.8x}: [0x%8.8llx - 0x%8.8llx)\n", Offset, LoPC, HiPC());
+  OS << format("{0x%8.8x}: [0x%8.8" PRIx64 " - 0x%8.8" PRIx64 ")\n",
+               Offset, LoPC, HiPC());
 }
 
 void DWARFDebugAranges::appendRange(uint32_t offset, uint64_t low_pc,

Modified: llvm/trunk/lib/DebugInfo/DWARFDebugLine.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/DebugInfo/DWARFDebugLine.cpp?rev=143799&r1=143798&r2=143799&view=diff
==============================================================================
--- llvm/trunk/lib/DebugInfo/DWARFDebugLine.cpp (original)
+++ llvm/trunk/lib/DebugInfo/DWARFDebugLine.cpp Sat Nov  5 03:57:40 2011
@@ -68,7 +68,7 @@
 }
 
 void DWARFDebugLine::Row::dump(raw_ostream &OS) const {
-  OS << format("0x%16.16llx %6u %6u", Address, Line, Column)
+  OS << format("0x%16.16" PRIx64 " %6u %6u", Address, Line, Column)
      << format(" %6u %3u ", File, Isa)
      << (IsStmt ? " is_stmt" : "")
      << (BasicBlock ? " basic_block" : "")

Modified: llvm/trunk/lib/DebugInfo/DWARFFormValue.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/DebugInfo/DWARFFormValue.cpp?rev=143799&r1=143798&r2=143799&view=diff
==============================================================================
--- llvm/trunk/lib/DebugInfo/DWARFFormValue.cpp (original)
+++ llvm/trunk/lib/DebugInfo/DWARFFormValue.cpp Sat Nov  5 03:57:40 2011
@@ -280,7 +280,7 @@
   case DW_FORM_block4:
     if (uvalue > 0) {
       switch (Form) {
-      case DW_FORM_block:  OS << format("<0x%llx> ", uvalue);            break;
+      case DW_FORM_block:  OS << format("<0x%" PRIx64 "> ", uvalue);     break;
       case DW_FORM_block1: OS << format("<0x%2.2x> ", (uint8_t)uvalue);  break;
       case DW_FORM_block2: OS << format("<0x%4.4x> ", (uint16_t)uvalue); break;
       case DW_FORM_block4: OS << format("<0x%8.8x> ", (uint32_t)uvalue); break;
@@ -330,11 +330,11 @@
     break;
   case DW_FORM_ref8:
     cu_relative_offset = true;
-    OS << format("cu + 0x%8.8llx", uvalue);
+    OS << format("cu + 0x%8.8" PRIx64, uvalue);
     break;
   case DW_FORM_ref_udata:
     cu_relative_offset = true;
-    OS << format("cu + 0x%llx", uvalue);
+    OS << format("cu + 0x%" PRIx64, uvalue);
     break;
 
     // All DW_FORM_indirect attributes should be resolved prior to calling

Modified: llvm/trunk/lib/Support/Timer.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Support/Timer.cpp?rev=143799&r1=143798&r2=143799&view=diff
==============================================================================
--- llvm/trunk/lib/Support/Timer.cpp (original)
+++ llvm/trunk/lib/Support/Timer.cpp Sat Nov  5 03:57:40 2011
@@ -184,7 +184,7 @@
   OS << "  ";
   
   if (Total.getMemUsed())
-    OS << format("%9lld  ", (long long)getMemUsed());
+    OS << format("%9" PRId64 "  ", (int64_t)getMemUsed());
 }
 
 

Modified: llvm/trunk/lib/Target/X86/InstPrinter/X86ATTInstPrinter.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/InstPrinter/X86ATTInstPrinter.cpp?rev=143799&r1=143798&r2=143799&view=diff
==============================================================================
--- llvm/trunk/lib/Target/X86/InstPrinter/X86ATTInstPrinter.cpp (original)
+++ llvm/trunk/lib/Target/X86/InstPrinter/X86ATTInstPrinter.cpp Sat Nov  5 03:57:40 2011
@@ -97,7 +97,7 @@
     O << '$' << (int64_t)Op.getImm();
     
     if (CommentStream && (Op.getImm() > 255 || Op.getImm() < -256))
-      *CommentStream << format("imm = 0x%llX\n", (long long)Op.getImm());
+      *CommentStream << format("imm = 0x%" PRIX64 "\n", (uint64_t)Op.getImm());
     
   } else {
     assert(Op.isExpr() && "unknown operand kind in printOperand");

Modified: llvm/trunk/tools/llvm-objdump/MachODump.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-objdump/MachODump.cpp?rev=143799&r1=143798&r2=143799&view=diff
==============================================================================
--- llvm/trunk/tools/llvm-objdump/MachODump.cpp (original)
+++ llvm/trunk/tools/llvm-objdump/MachODump.cpp Sat Nov  5 03:57:40 2011
@@ -459,7 +459,7 @@
                                      DebugOut, nulls())) {
             uint64_t SectAddress = 0;
             Sections[SectIdx].getAddress(SectAddress);
-            outs() << format("%8llx:\t", SectAddress + Index);
+            outs() << format("%8" PRIx64 ":\t", SectAddress + Index);
 
             DumpBytes(StringRef(Bytes.data() + Index, Size));
             IP->printInst(&Inst, outs(), "");
@@ -579,7 +579,7 @@
               outs() << FunctionMap[SectAddress + Inst.Address]-> getName()
                      << ":\n";
 
-            outs() << format("%8llx:\t", SectAddress + Inst.Address);
+            outs() << format("%8" PRIx64 ":\t", SectAddress + Inst.Address);
             DumpBytes(StringRef(Bytes.data() + Inst.Address, Inst.Size));
 
             if (fi->second.contains(fi->first)) // Indent simple loops.

Modified: llvm/trunk/tools/llvm-size/llvm-size.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-size/llvm-size.cpp?rev=143799&r1=143798&r2=143799&view=diff
==============================================================================
--- llvm/trunk/tools/llvm-size/llvm-size.cpp (original)
+++ llvm/trunk/tools/llvm-size/llvm-size.cpp Sat Nov  5 03:57:40 2011
@@ -96,13 +96,13 @@
   const char *radix_fmt = 0;
   switch (Radix) {
   case octal:
-    radix_fmt = "llo";
+    radix_fmt = PRIo64;
     break;
   case decimal:
-    radix_fmt = "llu";
+    radix_fmt = PRIu64;
     break;
   case hexadecimal:
-    radix_fmt = "llx";
+    radix_fmt = PRIx64;
     break;
   }
   if (OutputFormat == sysv) {
@@ -223,8 +223,8 @@
                      total_data,
                      total_bss);
     fmtbuf.clear();
-    fmt << "%7" << (Radix == octal ? "llo" : "llu") << " "
-        << "%7llx ";
+    fmt << "%7" << (Radix == octal ? PRIo64 : PRIu64) << " "
+        << "%7" PRIx64 " ";
     outs() << format(fmt.str().c_str(),
                      total,
                      total);



From benny.kra at googlemail.com  Sat Nov  5 04:45:18 2011
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Sat, 05 Nov 2011 09:45:18 -0000
Subject: [llvm-commits] [llvm] r143802 - in
 /llvm/trunk/include/llvm/Support: DataTypes.h.cmake DataTypes.h.in
Message-ID: <20111105094518.18E842A6C12C@llvm.org>

Author: d0k
Date: Sat Nov  5 04:45:17 2011
New Revision: 143802

URL: http://llvm.org/viewvc/llvm-project?rev=143802&view=rev
Log:
Fix pasto.

Modified:
    llvm/trunk/include/llvm/Support/DataTypes.h.cmake
    llvm/trunk/include/llvm/Support/DataTypes.h.in

Modified: llvm/trunk/include/llvm/Support/DataTypes.h.cmake
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/DataTypes.h.cmake?rev=143802&r1=143801&r2=143802&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Support/DataTypes.h.cmake (original)
+++ llvm/trunk/include/llvm/Support/DataTypes.h.cmake Sat Nov  5 04:45:17 2011
@@ -171,10 +171,10 @@
 # define PRId64 "I64d"
 #endif
 #ifndef PRIi64
-# define PRIu64 "I64i"
+# define PRIi64 "I64i"
 #endif
 #ifndef PRIo64
-# define PRIx64 "I64o"
+# define PRIo64 "I64o"
 #endif
 #ifndef PRIu64
 # define PRIu64 "I64u"

Modified: llvm/trunk/include/llvm/Support/DataTypes.h.in
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Support/DataTypes.h.in?rev=143802&r1=143801&r2=143802&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Support/DataTypes.h.in (original)
+++ llvm/trunk/include/llvm/Support/DataTypes.h.in Sat Nov  5 04:45:17 2011
@@ -171,10 +171,10 @@
 # define PRId64 "I64d"
 #endif
 #ifndef PRIi64
-# define PRIu64 "I64i"
+# define PRIi64 "I64i"
 #endif
 #ifndef PRIo64
-# define PRIx64 "I64o"
+# define PRIo64 "I64o"
 #endif
 #ifndef PRIu64
 # define PRIu64 "I64u"



From nicholas at mxc.ca  Sat Nov  5 05:48:42 2011
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sat, 05 Nov 2011 10:48:42 -0000
Subject: [llvm-commits] [llvm] r143808 - in /llvm/trunk:
 lib/Transforms/Scalar/DeadStoreElimination.cpp
 test/Transforms/DeadStoreElimination/free.ll
Message-ID: <20111105104842.708212A6C12C@llvm.org>

Author: nicholas
Date: Sat Nov  5 05:48:42 2011
New Revision: 143808

URL: http://llvm.org/viewvc/llvm-project?rev=143808&view=rev
Log:
Do simple cross-block DSE when we encounter a free statement. Fixes PR11240.

Modified:
    llvm/trunk/lib/Transforms/Scalar/DeadStoreElimination.cpp
    llvm/trunk/test/Transforms/DeadStoreElimination/free.ll

Modified: llvm/trunk/lib/Transforms/Scalar/DeadStoreElimination.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/DeadStoreElimination.cpp?rev=143808&r1=143807&r2=143808&view=diff
==============================================================================
--- llvm/trunk/lib/Transforms/Scalar/DeadStoreElimination.cpp (original)
+++ llvm/trunk/lib/Transforms/Scalar/DeadStoreElimination.cpp Sat Nov  5 05:48:42 2011
@@ -34,6 +34,7 @@
 #include "llvm/Support/Debug.h"
 #include "llvm/ADT/SmallPtrSet.h"
 #include "llvm/ADT/Statistic.h"
+#include "llvm/ADT/STLExtras.h"
 using namespace llvm;
 
 STATISTIC(NumFastStores, "Number of stores deleted");
@@ -43,25 +44,26 @@
   struct DSE : public FunctionPass {
     AliasAnalysis *AA;
     MemoryDependenceAnalysis *MD;
+    DominatorTree *DT;
 
     static char ID; // Pass identification, replacement for typeid
-    DSE() : FunctionPass(ID), AA(0), MD(0) {
+    DSE() : FunctionPass(ID), AA(0), MD(0), DT(0) {
       initializeDSEPass(*PassRegistry::getPassRegistry());
     }
 
     virtual bool runOnFunction(Function &F) {
       AA = &getAnalysis();
       MD = &getAnalysis();
-      DominatorTree &DT = getAnalysis();
+      DT = &getAnalysis();
 
       bool Changed = false;
       for (Function::iterator I = F.begin(), E = F.end(); I != E; ++I)
         // Only check non-dead blocks.  Dead blocks may have strange pointer
         // cycles that will confuse alias analysis.
-        if (DT.isReachableFromEntry(I))
+        if (DT->isReachableFromEntry(I))
           Changed |= runOnBasicBlock(*I);
 
-      AA = 0; MD = 0;
+      AA = 0; MD = 0; DT = 0;
       return Changed;
     }
 
@@ -549,37 +551,66 @@
   return MadeChange;
 }
 
+/// Find all blocks that will unconditionally lead to the block BB and append
+/// them to F.
+static void FindUnconditionalPreds(SmallVectorImpl &Blocks,
+                                   BasicBlock *BB, DominatorTree *DT) {
+  for (pred_iterator I = pred_begin(BB), E = pred_end(BB); I != E; ++I) {
+    BasicBlock *Pred = *I;
+    TerminatorInst *PredTI = Pred->getTerminator();
+    if (PredTI->getNumSuccessors() != 1)
+      continue;
+
+    if (DT->isReachableFromEntry(Pred))
+      Blocks.push_back(Pred);
+  }
+}
+
 /// HandleFree - Handle frees of entire structures whose dependency is a store
 /// to a field of that structure.
 bool DSE::HandleFree(CallInst *F) {
   bool MadeChange = false;
 
-  MemDepResult Dep = MD->getDependency(F);
+  AliasAnalysis::Location Loc = AliasAnalysis::Location(F->getOperand(0));
+  SmallVector Blocks;
+  Blocks.push_back(F->getParent());
+
+  while (!Blocks.empty()) {
+    BasicBlock *BB = Blocks.pop_back_val();
+    Instruction *InstPt = BB->getTerminator();
+    if (BB == F->getParent()) InstPt = F;
+
+    MemDepResult Dep = MD->getPointerDependencyFrom(Loc, false, InstPt, BB);
+    while (Dep.isDef() || Dep.isClobber()) {
+      Instruction *Dependency = Dep.getInst();
+      if (!hasMemoryWrite(Dependency) || !isRemovable(Dependency))
+        break;
+
+      Value *DepPointer =
+        GetUnderlyingObject(getStoredPointerOperand(Dependency));
 
-  while (Dep.isDef() || Dep.isClobber()) {
-    Instruction *Dependency = Dep.getInst();
-    if (!hasMemoryWrite(Dependency) || !isRemovable(Dependency))
-      return MadeChange;
-
-    Value *DepPointer =
-      GetUnderlyingObject(getStoredPointerOperand(Dependency));
-
-    // Check for aliasing.
-    if (!AA->isMustAlias(F->getArgOperand(0), DepPointer))
-      return MadeChange;
-
-    // DCE instructions only used to calculate that store
-    DeleteDeadInstruction(Dependency, *MD);
-    ++NumFastStores;
-    MadeChange = true;
-
-    // Inst's old Dependency is now deleted. Compute the next dependency,
-    // which may also be dead, as in
-    //    s[0] = 0;
-    //    s[1] = 0; // This has just been deleted.
-    //    free(s);
-    Dep = MD->getDependency(F);
-  };
+      // Check for aliasing.
+      if (!AA->isMustAlias(F->getArgOperand(0), DepPointer))
+        break;
+
+      Instruction *Next = llvm::next(BasicBlock::iterator(Dependency));
+
+      // DCE instructions only used to calculate that store
+      DeleteDeadInstruction(Dependency, *MD);
+      ++NumFastStores;
+      MadeChange = true;
+
+      // Inst's old Dependency is now deleted. Compute the next dependency,
+      // which may also be dead, as in
+      //    s[0] = 0;
+      //    s[1] = 0; // This has just been deleted.
+      //    free(s);
+      Dep = MD->getPointerDependencyFrom(Loc, false, Next, BB);
+    }
+
+    if (Dep.isNonLocal())
+      FindUnconditionalPreds(Blocks, BB, DT);
+  }
 
   return MadeChange;
 }

Modified: llvm/trunk/test/Transforms/DeadStoreElimination/free.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/DeadStoreElimination/free.ll?rev=143808&r1=143807&r2=143808&view=diff
==============================================================================
--- llvm/trunk/test/Transforms/DeadStoreElimination/free.ll (original)
+++ llvm/trunk/test/Transforms/DeadStoreElimination/free.ll Sat Nov  5 05:48:42 2011
@@ -2,6 +2,9 @@
 
 target datalayout = "e-p:64:64:64"
 
+declare void @free(i8* nocapture)
+declare noalias i8* @malloc(i64)
+
 ; CHECK: @test
 ; CHECK-NEXT: bitcast
 ; CHECK-NEXT: @free
@@ -26,10 +29,10 @@
 	ret void
 }
 
-; CHECK: @test4
+; CHECK: @test3
 ; CHECK-NOT: store
 ; CHECK: ret void
-define void @test4() {
+define void @test3() {
   %m = call i8* @malloc(i64 24)
   store i8 0, i8* %m
   %m1 = getelementptr i8* %m, i64 1
@@ -38,5 +41,20 @@
   ret void
 }
 
-declare void @free(i8*)
-declare i8* @malloc(i64)
+; PR11240
+; CHECK: @test4
+; CHECK-NOT: store
+; CHECK: ret void
+define void @test4(i1 %x) nounwind {
+entry:
+  %alloc1 = tail call noalias i8* @malloc(i64 4) nounwind
+  br i1 %x, label %skipinit1, label %init1
+
+init1:
+  store i8 1, i8* %alloc1
+  br label %skipinit1
+
+skipinit1:
+  tail call void @free(i8* %alloc1) nounwind
+  ret void
+}



From benny.kra at googlemail.com  Sat Nov  5 06:52:44 2011
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Sat, 05 Nov 2011 11:52:44 -0000
Subject: [llvm-commits] [llvm] r143809 - in /llvm/trunk:
 include/llvm/MC/MCObjectWriter.h include/llvm/MC/MCStreamer.h
 lib/CodeGen/AsmPrinter/AsmPrinterDwarf.cpp lib/MC/MCObjectWriter.cpp
 lib/MC/MCStreamer.cpp test/CodeGen/ARM/debug-info-qreg.ll
 test/CodeGen/ARM/debug-info-s16-reg.ll
 test/CodeGen/X86/2010-06-28-DbgEntryPC.ll
Message-ID: <20111105115245.258532A6C12C@llvm.org>

Author: d0k
Date: Sat Nov  5 06:52:44 2011
New Revision: 143809

URL: http://llvm.org/viewvc/llvm-project?rev=143809&view=rev
Log:
Add an option to pad an uleb128 to MCObjectWriter and remove the uleb128 encoding from the DWARF asm printer.

As a side effect we now print dwarf ulebs with .ascii directives.

Modified:
    llvm/trunk/include/llvm/MC/MCObjectWriter.h
    llvm/trunk/include/llvm/MC/MCStreamer.h
    llvm/trunk/lib/CodeGen/AsmPrinter/AsmPrinterDwarf.cpp
    llvm/trunk/lib/MC/MCObjectWriter.cpp
    llvm/trunk/lib/MC/MCStreamer.cpp
    llvm/trunk/test/CodeGen/ARM/debug-info-qreg.ll
    llvm/trunk/test/CodeGen/ARM/debug-info-s16-reg.ll
    llvm/trunk/test/CodeGen/X86/2010-06-28-DbgEntryPC.ll

Modified: llvm/trunk/include/llvm/MC/MCObjectWriter.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/MC/MCObjectWriter.h?rev=143809&r1=143808&r2=143809&view=diff
==============================================================================
--- llvm/trunk/include/llvm/MC/MCObjectWriter.h (original)
+++ llvm/trunk/include/llvm/MC/MCObjectWriter.h Sat Nov  5 06:52:44 2011
@@ -188,7 +188,8 @@
   /// Utility function to encode a SLEB128 value.
   static void EncodeSLEB128(int64_t Value, raw_ostream &OS);
   /// Utility function to encode a ULEB128 value.
-  static void EncodeULEB128(uint64_t Value, raw_ostream &OS);
+  static void EncodeULEB128(uint64_t Value, raw_ostream &OS,
+                            unsigned Padding = 0);
 };
 
 MCObjectWriter *createWinCOFFObjectWriter(raw_ostream &OS, bool is64Bit);

Modified: llvm/trunk/include/llvm/MC/MCStreamer.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/MC/MCStreamer.h?rev=143809&r1=143808&r2=143809&view=diff
==============================================================================
--- llvm/trunk/include/llvm/MC/MCStreamer.h (original)
+++ llvm/trunk/include/llvm/MC/MCStreamer.h Sat Nov  5 06:52:44 2011
@@ -420,7 +420,8 @@
 
     /// EmitULEB128Value - Special case of EmitULEB128Value that avoids the
     /// client having to pass in a MCExpr for constant integers.
-    void EmitULEB128IntValue(uint64_t Value, unsigned AddrSpace = 0);
+    void EmitULEB128IntValue(uint64_t Value, unsigned AddrSpace = 0,
+                             unsigned Padding = 0);
 
     /// EmitSLEB128Value - Special case of EmitSLEB128Value that avoids the
     /// client having to pass in a MCExpr for constant integers.

Modified: llvm/trunk/lib/CodeGen/AsmPrinter/AsmPrinterDwarf.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/AsmPrinter/AsmPrinterDwarf.cpp?rev=143809&r1=143808&r2=143809&view=diff
==============================================================================
--- llvm/trunk/lib/CodeGen/AsmPrinter/AsmPrinterDwarf.cpp (original)
+++ llvm/trunk/lib/CodeGen/AsmPrinter/AsmPrinterDwarf.cpp Sat Nov  5 06:52:44 2011
@@ -35,23 +35,8 @@
 void AsmPrinter::EmitSLEB128(int Value, const char *Desc) const {
   if (isVerbose() && Desc)
     OutStreamer.AddComment(Desc);
-    
-  if (MAI->hasLEB128()) {
-    OutStreamer.EmitSLEB128IntValue(Value);
-    return;
-  }
 
-  // If we don't have .sleb128, emit as .bytes.
-  int Sign = Value >> (8 * sizeof(Value) - 1);
-  bool IsMore;
-  
-  do {
-    unsigned char Byte = static_cast(Value & 0x7f);
-    Value >>= 7;
-    IsMore = Value != Sign || ((Byte ^ Sign) & 0x40) != 0;
-    if (IsMore) Byte |= 0x80;
-    OutStreamer.EmitIntValue(Byte, 1, /*addrspace*/0);
-  } while (IsMore);
+  OutStreamer.EmitSLEB128IntValue(Value);
 }
 
 /// EmitULEB128 - emit the specified signed leb128 value.
@@ -60,25 +45,7 @@
   if (isVerbose() && Desc)
     OutStreamer.AddComment(Desc);
 
-  // FIXME: Should we add a PadTo option to the streamer?
-  if (MAI->hasLEB128() && PadTo == 0) {
-    OutStreamer.EmitULEB128IntValue(Value); 
-    return;
-  }
-  
-  // If we don't have .uleb128 or we want to emit padding, emit as .bytes.
-  do {
-    unsigned char Byte = static_cast(Value & 0x7f);
-    Value >>= 7;
-    if (Value || PadTo != 0) Byte |= 0x80;
-    OutStreamer.EmitIntValue(Byte, 1, /*addrspace*/0);
-  } while (Value);
-
-  if (PadTo) {
-    if (PadTo > 1)
-      OutStreamer.EmitFill(PadTo - 1, 0x80/*fillval*/, 0/*addrspace*/);
-    OutStreamer.EmitFill(1, 0/*fillval*/, 0/*addrspace*/);
-  }
+  OutStreamer.EmitULEB128IntValue(Value, 0/*addrspace*/, PadTo);
 }
 
 /// EmitCFAByte - Emit a .byte 42 directive for a DW_CFA_xxx value.

Modified: llvm/trunk/lib/MC/MCObjectWriter.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/MC/MCObjectWriter.cpp?rev=143809&r1=143808&r2=143809&view=diff
==============================================================================
--- llvm/trunk/lib/MC/MCObjectWriter.cpp (original)
+++ llvm/trunk/lib/MC/MCObjectWriter.cpp Sat Nov  5 06:52:44 2011
@@ -33,14 +33,22 @@
 }
 
 /// Utility function to encode a ULEB128 value.
-void MCObjectWriter::EncodeULEB128(uint64_t Value, raw_ostream &OS) {
+void MCObjectWriter::EncodeULEB128(uint64_t Value, raw_ostream &OS,
+                                   unsigned Padding) {
   do {
     uint8_t Byte = Value & 0x7f;
     Value >>= 7;
-    if (Value != 0)
+    if (Value != 0 || Padding != 0)
       Byte |= 0x80; // Mark this byte that that more bytes will follow.
     OS << char(Byte);
   } while (Value != 0);
+
+  // Pad with 0x80 and emit a null byte at the end.
+  if (Padding != 0) {
+    for (; Padding != 1; --Padding)
+      OS << '\x80';
+    OS << '\x00';
+  }
 }
 
 bool

Modified: llvm/trunk/lib/MC/MCStreamer.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/MC/MCStreamer.cpp?rev=143809&r1=143808&r2=143809&view=diff
==============================================================================
--- llvm/trunk/lib/MC/MCStreamer.cpp (original)
+++ llvm/trunk/lib/MC/MCStreamer.cpp Sat Nov  5 06:52:44 2011
@@ -94,10 +94,11 @@
 
 /// EmitULEB128Value - Special case of EmitULEB128Value that avoids the
 /// client having to pass in a MCExpr for constant integers.
-void MCStreamer::EmitULEB128IntValue(uint64_t Value, unsigned AddrSpace) {
+void MCStreamer::EmitULEB128IntValue(uint64_t Value, unsigned AddrSpace,
+                                     unsigned Padding) {
   SmallString<32> Tmp;
   raw_svector_ostream OSE(Tmp);
-  MCObjectWriter::EncodeULEB128(Value, OSE);
+  MCObjectWriter::EncodeULEB128(Value, OSE, Padding);
   EmitBytes(OSE.str(), AddrSpace);
 }
 

Modified: llvm/trunk/test/CodeGen/ARM/debug-info-qreg.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/ARM/debug-info-qreg.ll?rev=143809&r1=143808&r2=143809&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/ARM/debug-info-qreg.ll (original)
+++ llvm/trunk/test/CodeGen/ARM/debug-info-qreg.ll Sat Nov  5 06:52:44 2011
@@ -3,13 +3,11 @@
 target triple = "thumbv7-apple-macosx10.6.7"
 
 ;CHECK: DW_OP_regx for Q register: D1
-;CHECK-NEXT: byte
-;CHECK-NEXT: byte
+;CHECK-NEXT: ascii
 ;CHECK-NEXT: DW_OP_piece 8
 ;CHECK-NEXT: byte   8
 ;CHECK-NEXT: DW_OP_regx for Q register: D2
-;CHECK-NEXT: byte
-;CHECK-NEXT: byte
+;CHECK-NEXT: ascii
 ;CHECK-NEXT: DW_OP_piece 8
 ;CHECK-NEXT: byte   8
 

Modified: llvm/trunk/test/CodeGen/ARM/debug-info-s16-reg.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/ARM/debug-info-s16-reg.ll?rev=143809&r1=143808&r2=143809&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/ARM/debug-info-s16-reg.ll (original)
+++ llvm/trunk/test/CodeGen/ARM/debug-info-s16-reg.ll Sat Nov  5 06:52:44 2011
@@ -2,8 +2,7 @@
 ; Radar 9309221
 ; Test dwarf reg no for s16
 ;CHECK: DW_OP_regx for S register
-;CHECK-NEXT: byte
-;CHECK-NEXT: byte
+;CHECK-NEXT: ascii
 ;CHECK-NEXT: DW_OP_bit_piece 32 0
 
 target datalayout = "e-p:32:32:32-i1:8:32-i8:8:32-i16:16:32-i32:32:32-i64:32:32-f32:32:32-f64:32:32-v64:32:64-v128:32:128-a0:0:32-n32"

Modified: llvm/trunk/test/CodeGen/X86/2010-06-28-DbgEntryPC.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/2010-06-28-DbgEntryPC.ll?rev=143809&r1=143808&r2=143809&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/X86/2010-06-28-DbgEntryPC.ll (original)
+++ llvm/trunk/test/CodeGen/X86/2010-06-28-DbgEntryPC.ll Sat Nov  5 06:52:44 2011
@@ -16,7 +16,7 @@
 ; CHECK-NEXT:	.byte	6                       ## DW_FORM_data4
 ; CHECK-NEXT:	.byte	27                      ## DW_AT_comp_dir
 ; CHECK-NEXT:	.byte	14                      ## DW_FORM_strp
-; CHECK-NEXT:	.byte	225                     ## DW_AT_APPLE_optimized
+; CHECK-NEXT:	.ascii	"\341\177"              ## DW_AT_APPLE_optimized
 
 %struct.a = type { i32, %struct.a* }
 



From benny.kra at googlemail.com  Sat Nov  5 07:13:21 2011
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Sat, 05 Nov 2011 12:13:21 -0000
Subject: [llvm-commits] [llvm] r143810 -
	/llvm/trunk/lib/Object/MachOObject.cpp
Message-ID: <20111105121321.F16D32A6C12C@llvm.org>

Author: d0k
Date: Sat Nov  5 07:13:21 2011
New Revision: 143810

URL: http://llvm.org/viewvc/llvm-project?rev=143810&view=rev
Log:
MachOObject: Use DataExtractor's uleb parser instead of rolling our own.

Modified:
    llvm/trunk/lib/Object/MachOObject.cpp

Modified: llvm/trunk/lib/Object/MachOObject.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Object/MachOObject.cpp?rev=143810&r1=143809&r2=143810&view=diff
==============================================================================
--- llvm/trunk/lib/Object/MachOObject.cpp (original)
+++ llvm/trunk/lib/Object/MachOObject.cpp Sat Nov  5 07:13:21 2011
@@ -10,11 +10,12 @@
 #include "llvm/Object/MachOObject.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/SmallVector.h"
-#include "llvm/Support/MemoryBuffer.h"
+#include "llvm/Support/DataExtractor.h"
+#include "llvm/Support/Debug.h"
 #include "llvm/Support/Host.h"
-#include "llvm/Support/SwapByteOrder.h"
+#include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/raw_ostream.h"
-#include "llvm/Support/Debug.h"
+#include "llvm/Support/SwapByteOrder.h"
 
 using namespace llvm;
 using namespace llvm::object;
@@ -359,25 +360,13 @@
 
 void MachOObject::ReadULEB128s(uint64_t Index,
                                SmallVectorImpl &Out) const {
-  const char *ptr = Buffer->getBufferStart() + Index;
+  DataExtractor extractor(Buffer->getBuffer(), true, 0);
+
+  uint32_t offset = Index;
   uint64_t data = 0;
-  uint64_t delta = 0;
-  uint32_t shift = 0;
-  while (true) {
-    assert(ptr < Buffer->getBufferEnd() && "index out of bounds");
-    assert(shift < 64 && "too big for uint64_t");
-
-    uint8_t byte = *ptr++;
-    delta |= ((byte & 0x7F) << shift);
-    shift += 7;
-    if (byte < 0x80) {
-      if (delta == 0)
-        break;
-      data += delta;
-      Out.push_back(data);
-      delta = 0;
-      shift = 0;
-    }
+  while (uint64_t delta = extractor.getULEB128(&offset)) {
+    data += delta;
+    Out.push_back(data);
   }
 }
 



From benny.kra at googlemail.com  Sat Nov  5 08:11:26 2011
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Sat, 05 Nov 2011 13:11:26 -0000
Subject: [llvm-commits] [llvm] r143811 - /llvm/trunk/lib/MC/MCStreamer.cpp
Message-ID: <20111105131126.2531C2A6C12C@llvm.org>

Author: d0k
Date: Sat Nov  5 08:11:25 2011
New Revision: 143811

URL: http://llvm.org/viewvc/llvm-project?rev=143811&view=rev
Log:
Twinify.

Modified:
    llvm/trunk/lib/MC/MCStreamer.cpp

Modified: llvm/trunk/lib/MC/MCStreamer.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/MC/MCStreamer.cpp?rev=143811&r1=143810&r2=143811&view=diff
==============================================================================
--- llvm/trunk/lib/MC/MCStreamer.cpp (original)
+++ llvm/trunk/lib/MC/MCStreamer.cpp Sat Nov  5 08:11:25 2011
@@ -16,7 +16,6 @@
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/ADT/SmallString.h"
-#include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/Twine.h"
 #include 
 using namespace llvm;
@@ -188,9 +187,8 @@
   if (!MAI.getSupportsDataRegions()) return;
 
   // Generate a unique symbol name.
-  MCSymbol *NewSym = Context.GetOrCreateSymbol(
-      Twine(MAI.getDataBeginLabelName()) +
-        utostr(UniqueDataBeginSuffix++));
+  MCSymbol *NewSym = Context.GetOrCreateSymbol(MAI.getDataBeginLabelName() +
+                                               Twine(UniqueDataBeginSuffix++));
   EmitLabel(NewSym);
 
   RegionIndicator = Data;
@@ -204,9 +202,8 @@
   if (!MAI.getSupportsDataRegions()) return;
 
   // Generate a unique symbol name.
-  MCSymbol *NewSym = Context.GetOrCreateSymbol(
-      Twine(MAI.getCodeBeginLabelName()) +
-        utostr(UniqueCodeBeginSuffix++));
+  MCSymbol *NewSym = Context.GetOrCreateSymbol(MAI.getCodeBeginLabelName() +
+                                               Twine(UniqueCodeBeginSuffix++));
   EmitLabel(NewSym);
 
   RegionIndicator = Code;
@@ -220,9 +217,9 @@
   if (!MAI.getSupportsDataRegions()) return;
 
   // Generate a unique symbol name.
-  MCSymbol *NewSym = Context.GetOrCreateSymbol(
-      Twine(MAI.getJumpTable8BeginLabelName()) +
-        utostr(UniqueDataBeginSuffix++));
+  MCSymbol *NewSym =
+    Context.GetOrCreateSymbol(MAI.getJumpTable8BeginLabelName() +
+                              Twine(UniqueDataBeginSuffix++));
   EmitLabel(NewSym);
 
   RegionIndicator = JumpTable8;
@@ -236,9 +233,9 @@
   if (!MAI.getSupportsDataRegions()) return;
 
   // Generate a unique symbol name.
-  MCSymbol *NewSym = Context.GetOrCreateSymbol(
-      Twine(MAI.getJumpTable16BeginLabelName()) +
-        utostr(UniqueDataBeginSuffix++));
+  MCSymbol *NewSym =
+    Context.GetOrCreateSymbol(MAI.getJumpTable16BeginLabelName() +
+                              Twine(UniqueDataBeginSuffix++));
   EmitLabel(NewSym);
 
   RegionIndicator = JumpTable16;
@@ -253,9 +250,9 @@
   if (!MAI.getSupportsDataRegions()) return;
 
   // Generate a unique symbol name.
-  MCSymbol *NewSym = Context.GetOrCreateSymbol(
-      Twine(MAI.getJumpTable32BeginLabelName()) +
-        utostr(UniqueDataBeginSuffix++));
+  MCSymbol *NewSym =
+    Context.GetOrCreateSymbol(MAI.getJumpTable32BeginLabelName() +
+                              Twine(UniqueDataBeginSuffix++));
   EmitLabel(NewSym);
 
   RegionIndicator = JumpTable32;



From benny.kra at googlemail.com  Sat Nov  5 10:35:00 2011
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Sat, 05 Nov 2011 15:35:00 -0000
Subject: [llvm-commits] [llvm] r143812 - in /llvm/trunk/lib/DebugInfo:
 DWARFDebugInfoEntry.cpp DWARFDebugInfoEntry.h
Message-ID: <20111105153500.97E412A6C12C@llvm.org>

Author: d0k
Date: Sat Nov  5 10:35:00 2011
New Revision: 143812

URL: http://llvm.org/viewvc/llvm-project?rev=143812&view=rev
Log:
Reduce the offsets in DwarfDebugInfoEntry to 32 bit, they're printed with %x and
that breaks on big-endian machines.

I have to clean up the 32/64 bit confusion in libDebugInfo some day.

Modified:
    llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.cpp
    llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.h

Modified: llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.cpp?rev=143812&r1=143811&r2=143812&view=diff
==============================================================================
--- llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.cpp (original)
+++ llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.cpp Sat Nov  5 10:35:00 2011
@@ -26,7 +26,7 @@
   uint32_t offset = Offset;
 
   if (debug_info_data.isValidOffset(offset)) {
-    uint64_t abbrCode = debug_info_data.getULEB128(&offset);
+    uint32_t abbrCode = debug_info_data.getULEB128(&offset);
 
     OS << format("\n0x%8.8x: ", Offset);
     if (abbrCode) {

Modified: llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.h?rev=143812&r1=143811&r2=143812&view=diff
==============================================================================
--- llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.h (original)
+++ llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.h Sat Nov  5 10:35:00 2011
@@ -23,7 +23,7 @@
 /// DWARFDebugInfoEntryMinimal - A DIE with only the minimum required data.
 class DWARFDebugInfoEntryMinimal {
   /// Offset within the .debug_info of the start of this entry.
-  uint64_t Offset;
+  uint32_t Offset;
 
   /// How many to subtract from "this" to get the parent.
   /// If zero this die has no parent.
@@ -52,7 +52,7 @@
 
   uint32_t getTag() const { return AbbrevDecl ? AbbrevDecl->getTag() : 0; }
   bool isNULL() const { return AbbrevDecl == 0; }
-  uint64_t getOffset() const { return Offset; }
+  uint32_t getOffset() const { return Offset; }
   uint32_t getNumAttributes() const {
     return !isNULL() ? AbbrevDecl->getNumAttributes() : 0;
   }



From jabbey at arxan.com  Sat Nov  5 10:52:46 2011
From: jabbey at arxan.com (Joe Abbey)
Date: Sat, 5 Nov 2011 10:52:46 -0500
Subject: [llvm-commits] [llvm] r143812 - in /llvm/trunk/lib/DebugInfo:
 DWARFDebugInfoEntry.cpp DWARFDebugInfoEntry.h
In-Reply-To: <20111105153500.97E412A6C12C@llvm.org>
References: <20111105153500.97E412A6C12C@llvm.org>
Message-ID: 

pr11300.ll still fails on PPC with this patch.

Please apply 

Index: lib/DebugInfo/DWARFDebugInfoEntry.cpp
===================================================================
--- lib/DebugInfo/DWARFDebugInfoEntry.cpp	(revision 143812)
+++ lib/DebugInfo/DWARFDebugInfoEntry.cpp	(working copy)
@@ -26,9 +26,9 @@
   uint32_t offset = Offset;
 
   if (debug_info_data.isValidOffset(offset)) {
+    OS << format("\n0x%8.8x: ", offset);
     uint32_t abbrCode = debug_info_data.getULEB128(&offset);
-
-    OS << format("\n0x%8.8x: ", Offset);
+    
     if (abbrCode) {
       if (AbbrevDecl) {
         const char *tagString = TagString(getTag());

Cheers,

Joe Abbey
Software Architect
Arxan Technologies, Inc.
1305 Cumberland Ave, Ste 215
West Lafayette, IN 47906
jabbey at arxan.com
www.arxan.com


On Nov 5, 2011, at 11:35 AM, Benjamin Kramer wrote:

> Author: d0k
> Date: Sat Nov  5 10:35:00 2011
> New Revision: 143812
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=143812&view=rev
> Log:
> Reduce the offsets in DwarfDebugInfoEntry to 32 bit, they're printed with %x and
> that breaks on big-endian machines.
> 
> I have to clean up the 32/64 bit confusion in libDebugInfo some day.
> 
> Modified:
>    llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.cpp
>    llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.h
> 
> Modified: llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.cpp
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.cpp?rev=143812&r1=143811&r2=143812&view=diff
> ==============================================================================
> --- llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.cpp (original)
> +++ llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.cpp Sat Nov  5 10:35:00 2011
> @@ -26,7 +26,7 @@
>   uint32_t offset = Offset;
> 
>   if (debug_info_data.isValidOffset(offset)) {
> -    uint64_t abbrCode = debug_info_data.getULEB128(&offset);
> +    uint32_t abbrCode = debug_info_data.getULEB128(&offset);
> 
>     OS << format("\n0x%8.8x: ", Offset);
>     if (abbrCode) {
> 
> Modified: llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.h
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.h?rev=143812&r1=143811&r2=143812&view=diff
> ==============================================================================
> --- llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.h (original)
> +++ llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.h Sat Nov  5 10:35:00 2011
> @@ -23,7 +23,7 @@
> /// DWARFDebugInfoEntryMinimal - A DIE with only the minimum required data.
> class DWARFDebugInfoEntryMinimal {
>   /// Offset within the .debug_info of the start of this entry.
> -  uint64_t Offset;
> +  uint32_t Offset;
> 
>   /// How many to subtract from "this" to get the parent.
>   /// If zero this die has no parent.
> @@ -52,7 +52,7 @@
> 
>   uint32_t getTag() const { return AbbrevDecl ? AbbrevDecl->getTag() : 0; }
>   bool isNULL() const { return AbbrevDecl == 0; }
> -  uint64_t getOffset() const { return Offset; }
> +  uint32_t getOffset() const { return Offset; }
>   uint32_t getNumAttributes() const {
>     return !isNULL() ? AbbrevDecl->getNumAttributes() : 0;
>   }
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111105/ef8b9c76/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4350 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111105/ef8b9c76/attachment-0001.bin 

From jabbey at arxan.com  Sat Nov  5 10:57:20 2011
From: jabbey at arxan.com (Joe Abbey)
Date: Sat, 5 Nov 2011 10:57:20 -0500
Subject: [llvm-commits] [llvm] r143812 - in /llvm/trunk/lib/DebugInfo:
 DWARFDebugInfoEntry.cpp DWARFDebugInfoEntry.h
In-Reply-To: 
References: <20111105153500.97E412A6C12C@llvm.org>
	
Message-ID: 

Whoops,

It works just fine 

Joe

Joe Abbey
Software Architect
Arxan Technologies, Inc.
1305 Cumberland Ave, Ste 215
West Lafayette, IN 47906
jabbey at arxan.com
www.arxan.com

On Nov 5, 2011, at 11:52 AM, Joe Abbey wrote:

> pr11300.ll still fails on PPC with this patch.
> 
> Please apply 
> 
> Index: lib/DebugInfo/DWARFDebugInfoEntry.cpp
> ===================================================================
> --- lib/DebugInfo/DWARFDebugInfoEntry.cpp	(revision 143812)
> +++ lib/DebugInfo/DWARFDebugInfoEntry.cpp	(working copy)
> @@ -26,9 +26,9 @@
>    uint32_t offset = Offset;
>  
>    if (debug_info_data.isValidOffset(offset)) {
> +    OS << format("\n0x%8.8x: ", offset);
>      uint32_t abbrCode = debug_info_data.getULEB128(&offset);
> -
> -    OS << format("\n0x%8.8x: ", Offset);
> +    
>      if (abbrCode) {
>        if (AbbrevDecl) {
>          const char *tagString = TagString(getTag());
> 
> Cheers,
> 
> Joe Abbey
> Software Architect
> Arxan Technologies, Inc.
> 1305 Cumberland Ave, Ste 215
> West Lafayette, IN 47906
> jabbey at arxan.com
> www.arxan.com
> 
> 
> On Nov 5, 2011, at 11:35 AM, Benjamin Kramer wrote:
> 
>> Author: d0k
>> Date: Sat Nov  5 10:35:00 2011
>> New Revision: 143812
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=143812&view=rev
>> Log:
>> Reduce the offsets in DwarfDebugInfoEntry to 32 bit, they're printed with %x and
>> that breaks on big-endian machines.
>> 
>> I have to clean up the 32/64 bit confusion in libDebugInfo some day.
>> 
>> Modified:
>>    llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.cpp
>>    llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.h
>> 
>> Modified: llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.cpp
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.cpp?rev=143812&r1=143811&r2=143812&view=diff
>> ==============================================================================
>> --- llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.cpp (original)
>> +++ llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.cpp Sat Nov  5 10:35:00 2011
>> @@ -26,7 +26,7 @@
>>   uint32_t offset = Offset;
>> 
>>   if (debug_info_data.isValidOffset(offset)) {
>> -    uint64_t abbrCode = debug_info_data.getULEB128(&offset);
>> +    uint32_t abbrCode = debug_info_data.getULEB128(&offset);
>> 
>>     OS << format("\n0x%8.8x: ", Offset);
>>     if (abbrCode) {
>> 
>> Modified: llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.h
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.h?rev=143812&r1=143811&r2=143812&view=diff
>> ==============================================================================
>> --- llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.h (original)
>> +++ llvm/trunk/lib/DebugInfo/DWARFDebugInfoEntry.h Sat Nov  5 10:35:00 2011
>> @@ -23,7 +23,7 @@
>> /// DWARFDebugInfoEntryMinimal - A DIE with only the minimum required data.
>> class DWARFDebugInfoEntryMinimal {
>>   /// Offset within the .debug_info of the start of this entry.
>> -  uint64_t Offset;
>> +  uint32_t Offset;
>> 
>>   /// How many to subtract from "this" to get the parent.
>>   /// If zero this die has no parent.
>> @@ -52,7 +52,7 @@
>> 
>>   uint32_t getTag() const { return AbbrevDecl ? AbbrevDecl->getTag() : 0; }
>>   bool isNULL() const { return AbbrevDecl == 0; }
>> -  uint64_t getOffset() const { return Offset; }
>> +  uint32_t getOffset() const { return Offset; }
>>   uint32_t getNumAttributes() const {
>>     return !isNULL() ? AbbrevDecl->getNumAttributes() : 0;
>>   }
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111105/4720efde/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4350 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111105/4720efde/attachment.bin 

From benny.kra at googlemail.com  Sat Nov  5 11:01:13 2011
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Sat, 05 Nov 2011 16:01:13 -0000
Subject: [llvm-commits] [llvm] r143814 - in /llvm/trunk/lib/DebugInfo:
 DWARFDebugAbbrev.cpp DWARFDebugAbbrev.h DWARFDebugLine.cpp
 DWARFFormValue.cpp
Message-ID: <20111105160114.044F02A6C12C@llvm.org>

Author: d0k
Date: Sat Nov  5 11:01:13 2011
New Revision: 143814

URL: http://llvm.org/viewvc/llvm-project?rev=143814&view=rev
Log:
Audited all the format strings in libDebugInfo and fixed those that didn't match the types.

Modified:
    llvm/trunk/lib/DebugInfo/DWARFDebugAbbrev.cpp
    llvm/trunk/lib/DebugInfo/DWARFDebugAbbrev.h
    llvm/trunk/lib/DebugInfo/DWARFDebugLine.cpp
    llvm/trunk/lib/DebugInfo/DWARFFormValue.cpp

Modified: llvm/trunk/lib/DebugInfo/DWARFDebugAbbrev.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/DebugInfo/DWARFDebugAbbrev.cpp?rev=143814&r1=143813&r2=143814&view=diff
==============================================================================
--- llvm/trunk/lib/DebugInfo/DWARFDebugAbbrev.cpp (original)
+++ llvm/trunk/lib/DebugInfo/DWARFDebugAbbrev.cpp Sat Nov  5 11:01:13 2011
@@ -83,7 +83,7 @@
 
   DWARFAbbreviationDeclarationCollMapConstIter pos;
   for (pos = AbbrevCollMap.begin(); pos != AbbrevCollMap.end(); ++pos) {
-    OS << format("Abbrev table for offset: 0x%8.8x\n", pos->first);
+    OS << format("Abbrev table for offset: 0x%8.8" PRIx64 "\n", pos->first);
     pos->second.dump(OS);
   }
 }

Modified: llvm/trunk/lib/DebugInfo/DWARFDebugAbbrev.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/DebugInfo/DWARFDebugAbbrev.h?rev=143814&r1=143813&r2=143814&view=diff
==============================================================================
--- llvm/trunk/lib/DebugInfo/DWARFDebugAbbrev.h (original)
+++ llvm/trunk/lib/DebugInfo/DWARFDebugAbbrev.h Sat Nov  5 11:01:13 2011
@@ -25,21 +25,21 @@
   DWARFAbbreviationDeclarationCollConstIter;
 
 class DWARFAbbreviationDeclarationSet {
-  uint64_t Offset;
+  uint32_t Offset;
   uint32_t IdxOffset;
   std::vector Decls;
   public:
   DWARFAbbreviationDeclarationSet()
     : Offset(0), IdxOffset(0) {}
 
-  DWARFAbbreviationDeclarationSet(uint64_t offset, uint32_t idxOffset)
+  DWARFAbbreviationDeclarationSet(uint32_t offset, uint32_t idxOffset)
     : Offset(offset), IdxOffset(idxOffset) {}
 
   void clear() {
     IdxOffset = 0;
     Decls.clear();
   }
-  uint64_t getOffset() const { return Offset; }
+  uint32_t getOffset() const { return Offset; }
   void dump(raw_ostream &OS) const;
   bool extract(DataExtractor data, uint32_t* offset_ptr);
 

Modified: llvm/trunk/lib/DebugInfo/DWARFDebugLine.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/DebugInfo/DWARFDebugLine.cpp?rev=143814&r1=143813&r2=143814&view=diff
==============================================================================
--- llvm/trunk/lib/DebugInfo/DWARFDebugLine.cpp (original)
+++ llvm/trunk/lib/DebugInfo/DWARFDebugLine.cpp Sat Nov  5 11:01:13 2011
@@ -41,8 +41,9 @@
           "----------------\n";
     for (uint32_t i = 0; i < FileNames.size(); ++i) {
       const FileNameEntry& fileEntry = FileNames[i];
-      OS << format("file_names[%3u] %4u ", i+1, fileEntry.DirIdx)
-         << format("0x%8.8x 0x%8.8x ", fileEntry.ModTime, fileEntry.Length)
+      OS << format("file_names[%3u] %4" PRIu64 " ", i+1, fileEntry.DirIdx)
+         << format("0x%8.8" PRIx64 " 0x%8.8" PRIx64 " ",
+                   fileEntry.ModTime, fileEntry.Length)
          << fileEntry.Name << '\n';
     }
   }

Modified: llvm/trunk/lib/DebugInfo/DWARFFormValue.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/DebugInfo/DWARFFormValue.cpp?rev=143814&r1=143813&r2=143814&view=diff
==============================================================================
--- llvm/trunk/lib/DebugInfo/DWARFFormValue.cpp (original)
+++ llvm/trunk/lib/DebugInfo/DWARFFormValue.cpp Sat Nov  5 11:01:13 2011
@@ -263,12 +263,12 @@
   bool cu_relative_offset = false;
 
   switch (Form) {
-  case DW_FORM_addr:      OS << format("0x%016x", uvalue); break;
+  case DW_FORM_addr:      OS << format("0x%016" PRIx64, uvalue); break;
   case DW_FORM_flag:
-  case DW_FORM_data1:     OS << format("0x%02x", uvalue);  break;
-  case DW_FORM_data2:     OS << format("0x%04x", uvalue);  break;
-  case DW_FORM_data4:     OS << format("0x%08x", uvalue);  break;
-  case DW_FORM_data8:     OS << format("0x%016x", uvalue); break;
+  case DW_FORM_data1:     OS << format("0x%02x", (uint8_t)uvalue); break;
+  case DW_FORM_data2:     OS << format("0x%04x", (uint16_t)uvalue); break;
+  case DW_FORM_data4:     OS << format("0x%08x", (uint32_t)uvalue); break;
+  case DW_FORM_data8:     OS << format("0x%016" PRIx64, uvalue); break;
   case DW_FORM_string:
     OS << '"';
     OS.write_escaped(getAsCString(NULL));
@@ -314,7 +314,7 @@
     break;
   }
   case DW_FORM_ref_addr:
-    OS << format("0x%016x", uvalue);
+    OS << format("0x%016" PRIx64, uvalue);
     break;
   case DW_FORM_ref1:
     cu_relative_offset = true;
@@ -348,7 +348,7 @@
   }
 
   if (cu_relative_offset)
-    OS << format(" => {0x%8.8x}", (uvalue + (cu ? cu->getOffset() : 0)));
+    OS << format(" => {0x%8.8"PRIx64"}", (uvalue + (cu ? cu->getOffset() : 0)));
 }
 
 const char*



From benny.kra at googlemail.com  Sat Nov  5 11:20:52 2011
From: benny.kra at googlemail.com (Benjamin Kramer)
Date: Sat, 05 Nov 2011 16:20:52 -0000
Subject: [llvm-commits] [llvm] r143815 - /llvm/trunk/test/lit.cfg
Message-ID: <20111105162053.09A712A6C12C@llvm.org>

Author: d0k
Date: Sat Nov  5 11:20:52 2011
New Revision: 143815

URL: http://llvm.org/viewvc/llvm-project?rev=143815&view=rev
Log:
Update lit's list of tools.

Modified:
    llvm/trunk/test/lit.cfg

Modified: llvm/trunk/test/lit.cfg
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/lit.cfg?rev=143815&r1=143814&r2=143815&view=diff
==============================================================================
--- llvm/trunk/test/lit.cfg (original)
+++ llvm/trunk/test/lit.cfg Sat Nov  5 11:20:52 2011
@@ -162,12 +162,14 @@
                 r"\bllc\b",             r"\blli\b",
                 r"\bllvm-ar\b",         r"\bllvm-as\b",
                 r"\bllvm-bcanalyzer\b", r"\bllvm-config\b",
-                r"\bllvm-diff\b",       r"\bllvm-dis\b",
+                r"\bllvm-cov\b",        r"\bllvm-diff\b",
+                r"\bllvm-dis\b",        r"\bllvm-dwarfdump\b",
                 r"\bllvm-extract\b",    r"\bllvm-ld\b",
                 r"\bllvm-link\b",       r"\bllvm-mc\b",
-                r"\bllvm-nm\b",         r"\bllvm-prof\b",
-                r"\bllvm-ranlib\b",     r"\bllvm-shlib\b",
-                r"\bllvm-stub\b",       r"\bllvm2cpp\b",
+                r"\bllvm-nm\b",         r"\bllvm-objdump\b",
+                r"\bllvm-prof\b",       r"\bllvm-ranlib\b",
+                r"\bllvm-rtdyld\b",     r"\bllvm-shlib\b",
+                r"\bllvm-size\b",       r"\bllvm-stub\b",
                 # Don't match '-llvmc'.
                 r"(?

Author: tbrethou
Date: Sat Nov  5 14:40:17 2011
New Revision: 143817

URL: http://llvm.org/viewvc/llvm-project?rev=143817&view=rev
Log:
Add agenda.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143817&r1=143816&r2=143817&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 14:40:17 2011
@@ -76,18 +76,55 @@
 
 
 Agenda
-The deadline for talk proposals has passed. Those who submitted a talk proposal will be notified of their status shortly. The agenda will be posted closer to the meeting.
- 
 
-There will be 3 classes of sessions
-
Keynote
-Technical
-Birds-of-a-feather (BoF).
- 
-
-For examples from last year's meeting, visit the following:
-http://llvm.org/devmtg/2010-11/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Time Talk Location
9:00 - 9:20 Welcome
Chris Lattner, Apple Inc. Main Hall
9:20 - 10:05 Integrating LLVM into FreeBSD
Brooks Davis, The FreeBSD Project Main Hall
Intel OpenCL SDK Vectorizer
Nadav Rotem, Intel Second Hall
10:05 - 10:50 Clang MapReduce -- Automatic C++ Refactoring at Google Scale
Chandler Carruth, Google Main Hall
PTX Back-End: GPU Programming With LLVM
Justin Holewinski, Ohio State Second Hall
Improving LLVM Testing
David Blaikie, Microsoft TBD
10:50 - 11:05 Break TBD
11:05 - 11:50 Extending Clang
Doug Gregor, Apple Inc. Main Hall
Porting LLVM to a Next Generation DSP 
Taylor Simpson, QuIC Second Hall
11:50 - 12:35 DXR: Semantic Code Browsing with Clang
Joshua Cranmer, Mozilla Main Hall
LLVM MC In Practice
Jim Grosbach, Owen Anderson Apple Inc. Second Hall
12:35 - 1:35 Lunch TBD
1:35 - 2:20 Using clang in the Chromium project
Nico Weber, Hans Wennborg, Google Main Hall
Polly - First successful optimizations - How to proceed?
Tobias Grosser, ENS/INRIA Second Hall
MC Linkers BOF
Luba Tang, Mediatek TBD
2:20 - 3:05 Android Renderscript
Stephen Hines, Google Main Hall
SKIR: Just-in-Time Compilation for Parallelism with LLVM
Jeff Fifield, University of Colorado Second Hall
Improving the Clang Driver
James Molloy, ARM TBD
3:05 - 3:45 Posters TBD
3:45 - 4:30 Register Allocation in LLVM 3.0 
Jakob Olesen, Apple Main Hall
Exporting 3D scenes from Maya to WebGL using clang and LLVM
Jochen Wilhelmy, consultant Second Hall
4:30 - 5:15 Super-optimizing LLVM IR
Duncan Sands, DeepBlueCapital Main Hall
Finding races and memory errors with LLVM instrumentation 
Konstantin Serebryany, Google Second Hall
Bitcode Portability/Versioning 
Stephen Hines, David Sehr, Google TBD
4:30 - 5:10 Thread Safety Annotations in Clang
DeLesley Hutchins, Google Almaden Ballroom
Backend/Infrastructure Super BoF
Jim Grosbach, Apple Second Hall
Community Event Planning
David Kipping, Qualcomm TBD
6:30 - 9:30 Dinner (Il Fornaio - Separate registration required) 
 
+
 Dinner
 Dinner attendance is capped at 140 and you must select this option during the registration process in order to attend.
 Dinner will be held after the meeting has concluded. The exact start time will be set once the meeting agenda is formalized. Dinner will be held at Il Fornaio which is within walking distance of the Marriott.



From tonic at nondot.org  Sat Nov  5 14:44:44 2011
From: tonic at nondot.org (Tanya Lattner)
Date: Sat, 05 Nov 2011 19:44:44 -0000
Subject: [llvm-commits] [www] r143818 - /www/trunk/devmtg/2011-11/index.html
Message-ID: <20111105194444.56F9D2A6C12C@llvm.org>

Author: tbrethou
Date: Sat Nov  5 14:44:43 2011
New Revision: 143818

URL: http://llvm.org/viewvc/llvm-project?rev=143818&view=rev
Log:
Clean up table.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143818&r1=143817&r2=143818&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 14:44:43 2011
@@ -83,7 +83,7 @@
 
 9:00 - 9:20Welcome
Chris Lattner, Apple Inc.Main Hall
 
-9:20 - 10:05Integrating LLVM into FreeBSD
Brooks Davis, The FreeBSD ProjectMain Hall
+9:20 - 10:05Integrating LLVM into FreeBSD
Brooks Davis, The FreeBSD ProjectMain Hall
 Intel OpenCL SDK Vectorizer
Nadav Rotem, IntelSecond Hall
 
 10:05 - 10:50Clang MapReduce -- Automatic C++ Refactoring at Google Scale
Chandler Carruth, GoogleMain Hall
@@ -108,9 +108,9 @@
 SKIR: Just-in-Time Compilation for Parallelism with LLVM
Jeff Fifield, University of ColoradoSecond Hall
 Improving the Clang Driver
James Molloy, ARMTBD
 
-3:05 - 3:45PostersTBD
+3:05 - 3:45PostersTBD
 
-3:45 - 4:30Register Allocation in LLVM 3.0 
Jakob Olesen, AppleMain Hall
+3:45 - 4:30Register Allocation in LLVM 3.0 
Jakob Olesen, AppleMain Hall
 Exporting 3D scenes from Maya to WebGL using clang and LLVM
Jochen Wilhelmy, consultantSecond Hall
 
 4:30 - 5:15Super-optimizing LLVM IR
Duncan Sands, DeepBlueCapitalMain Hall



From tonic at nondot.org  Sat Nov  5 14:45:50 2011
From: tonic at nondot.org (Tanya Lattner)
Date: Sat, 05 Nov 2011 19:45:50 -0000
Subject: [llvm-commits] [www] r143819 - /www/trunk/devmtg/2011-11/index.html
Message-ID: <20111105194550.EE7A82A6C12C@llvm.org>

Author: tbrethou
Date: Sat Nov  5 14:45:50 2011
New Revision: 143819

URL: http://llvm.org/viewvc/llvm-project?rev=143819&view=rev
Log:
Update hall.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143819&r1=143818&r2=143819&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 14:45:50 2011
@@ -117,7 +117,7 @@
 Finding races and memory errors with LLVM instrumentation 
Konstantin Serebryany, GoogleSecond Hall
 Bitcode Portability/Versioning 
Stephen Hines, David Sehr, GoogleTBD
 
-4:30 - 5:10Thread Safety Annotations in Clang
DeLesley Hutchins, GoogleAlmaden Ballroom
+4:30 - 5:10Thread Safety Annotations in Clang
DeLesley Hutchins, GoogleMain Hall
 Backend/Infrastructure Super BoF
Jim Grosbach, AppleSecond Hall
 Community Event Planning
David Kipping, QualcommTBD
 



From tonic at nondot.org  Sat Nov  5 15:07:29 2011
From: tonic at nondot.org (Tanya Lattner)
Date: Sat, 05 Nov 2011 20:07:29 -0000
Subject: [llvm-commits] [www] r143820 - /www/trunk/devmtg/2011-11/index.html
Message-ID: <20111105200730.089242A6C12C@llvm.org>

Author: tbrethou
Date: Sat Nov  5 15:07:29 2011
New Revision: 143820

URL: http://llvm.org/viewvc/llvm-project?rev=143820&view=rev
Log:
Update some titles.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143820&r1=143819&r2=143820&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 15:07:29 2011
@@ -88,7 +88,7 @@
 
 10:05 - 10:50Clang MapReduce -- Automatic C++ Refactoring at Google Scale
Chandler Carruth, GoogleMain Hall
 PTX Back-End: GPU Programming With LLVM
Justin Holewinski, Ohio StateSecond Hall
-Improving LLVM Testing
David Blaikie, MicrosoftTBD
+Improving LLVM Testing BOF
David BlaikieTBD
 
 10:50 - 11:05BreakTBD
 
@@ -106,7 +106,7 @@
 
 2:20 - 3:05Android Renderscript
Stephen Hines, GoogleMain Hall
 SKIR: Just-in-Time Compilation for Parallelism with LLVM
Jeff Fifield, University of ColoradoSecond Hall
-Improving the Clang Driver
James Molloy, ARMTBD
+Improving the Clang Driver BOF
James Molloy, ARMTBD
 
 3:05 - 3:45PostersTBD
 
@@ -115,10 +115,10 @@
 
 4:30 - 5:15Super-optimizing LLVM IR
Duncan Sands, DeepBlueCapitalMain Hall
 Finding races and memory errors with LLVM instrumentation 
Konstantin Serebryany, GoogleSecond Hall
-Bitcode Portability/Versioning 
Stephen Hines, David Sehr, GoogleTBD
+Bitcode Portability/Versioning BOF
Stephen Hines, David Sehr, GoogleTBD
 
 4:30 - 5:10Thread Safety Annotations in Clang
DeLesley Hutchins, GoogleMain Hall
-Backend/Infrastructure Super BoF
Jim Grosbach, AppleSecond Hall
+Backend/Infrastructure Super BoF
Jim Grosbach, Apple Inc.Second Hall
 Community Event Planning
David Kipping, QualcommTBD
 
 6:30 - 9:30Dinner (Il Fornaio - Separate registration required)



From mcrosier at apple.com  Sat Nov  5 15:16:15 2011
From: mcrosier at apple.com (Chad Rosier)
Date: Sat, 05 Nov 2011 20:16:15 -0000
Subject: [llvm-commits] [llvm] r143821 - in /llvm/trunk:
 lib/Target/ARM/ARMFastISel.cpp test/CodeGen/ARM/fast-isel-call.ll
Message-ID: <20111105201615.662902A6C12C@llvm.org>

Author: mcrosier
Date: Sat Nov  5 15:16:15 2011
New Revision: 143821

URL: http://llvm.org/viewvc/llvm-project?rev=143821&view=rev
Log:
Add support for passing i1, i8, and i16 call parameters.  Also, be sure to
zero-extend the constant integer encoding.  Test case provides testing for
both call parameters and materialization of i1, i8, and i16 types.

Added:
    llvm/trunk/test/CodeGen/ARM/fast-isel-call.ll
Modified:
    llvm/trunk/lib/Target/ARM/ARMFastISel.cpp

Modified: llvm/trunk/lib/Target/ARM/ARMFastISel.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMFastISel.cpp?rev=143821&r1=143820&r2=143821&view=diff
==============================================================================
--- llvm/trunk/lib/Target/ARM/ARMFastISel.cpp (original)
+++ llvm/trunk/lib/Target/ARM/ARMFastISel.cpp Sat Nov  5 15:16:15 2011
@@ -557,7 +557,7 @@
     unsigned ImmReg = createResultReg(TLI.getRegClassFor(SrcVT));
     AddOptionalDefs(BuildMI(*FuncInfo.MBB, FuncInfo.InsertPt, DL,
                             TII.get(Opc), ImmReg)
-                    .addImm(CI->getSExtValue()));
+                    .addImm(CI->getZExtValue()));
     return ImmReg;
   }
 
@@ -1599,33 +1599,21 @@
     switch (VA.getLocInfo()) {
       case CCValAssign::Full: break;
       case CCValAssign::SExt: {
-        bool Emitted = FastEmitExtend(ISD::SIGN_EXTEND, VA.getLocVT(),
-                                         Arg, ArgVT, Arg);
-        assert(Emitted && "Failed to emit a sext!"); (void)Emitted;
-        Emitted = true;
-        ArgVT = VA.getLocVT();
+        EVT DestVT = VA.getLocVT();
+        unsigned ResultReg = ARMEmitIntExt(ArgVT, Arg, DestVT,
+                                           /*isZExt*/false);
+        assert (ResultReg != 0 && "Failed to emit a sext");
+        Arg = ResultReg;
         break;
       }
+      case CCValAssign::AExt:
+        // Intentional fall-through.  Handle AExt and ZExt.
       case CCValAssign::ZExt: {
-        bool Emitted = FastEmitExtend(ISD::ZERO_EXTEND, VA.getLocVT(),
-                                         Arg, ArgVT, Arg);
-        assert(Emitted && "Failed to emit a zext!"); (void)Emitted;
-        Emitted = true;
-        ArgVT = VA.getLocVT();
-        break;
-      }
-      case CCValAssign::AExt: {
-        bool Emitted = FastEmitExtend(ISD::ANY_EXTEND, VA.getLocVT(),
-                                         Arg, ArgVT, Arg);
-        if (!Emitted)
-          Emitted = FastEmitExtend(ISD::ZERO_EXTEND, VA.getLocVT(),
-                                      Arg, ArgVT, Arg);
-        if (!Emitted)
-          Emitted = FastEmitExtend(ISD::SIGN_EXTEND, VA.getLocVT(),
-                                      Arg, ArgVT, Arg);
-
-        assert(Emitted && "Failed to emit a aext!"); (void)Emitted;
-        ArgVT = VA.getLocVT();
+        EVT DestVT = VA.getLocVT();
+        unsigned ResultReg = ARMEmitIntExt(ArgVT, Arg, DestVT,
+                                           /*isZExt*/true);
+        assert (ResultReg != 0 && "Failed to emit a sext");
+        Arg = ResultReg;
         break;
       }
       case CCValAssign::BCvt: {
@@ -1643,7 +1631,7 @@
     if (VA.isRegLoc() && !VA.needsCustom()) {
       BuildMI(*FuncInfo.MBB, FuncInfo.InsertPt, DL, TII.get(TargetOpcode::COPY),
               VA.getLocReg())
-      .addReg(Arg);
+        .addReg(Arg);
       RegArgs.push_back(VA.getLocReg());
     } else if (VA.needsCustom()) {
       // TODO: We need custom lowering for vector (v2f64) args.
@@ -1962,8 +1950,8 @@
 
     Type *ArgTy = (*i)->getType();
     MVT ArgVT;
-    // FIXME: Should be able to handle i1, i8, and/or i16 parameters.
-    if (!isTypeLegal(ArgTy, ArgVT))
+    if (!isTypeLegal(ArgTy, ArgVT) && ArgVT != MVT::i16 && ArgVT != MVT::i8 &&
+        ArgVT != MVT::i1)
       return false;
     unsigned OriginalAlignment = TD.getABITypeAlignment(ArgTy);
     Flags.setOrigAlign(OriginalAlignment);

Added: llvm/trunk/test/CodeGen/ARM/fast-isel-call.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/ARM/fast-isel-call.ll?rev=143821&view=auto
==============================================================================
--- llvm/trunk/test/CodeGen/ARM/fast-isel-call.ll (added)
+++ llvm/trunk/test/CodeGen/ARM/fast-isel-call.ll Sat Nov  5 15:16:15 2011
@@ -0,0 +1,67 @@
+; RUN: llc < %s -O0 -fast-isel-abort -relocation-model=dynamic-no-pic -mtriple=armv7-apple-darwin | FileCheck %s --check-prefix=ARM
+; RUN: llc < %s -O0 -fast-isel-abort -relocation-model=dynamic-no-pic -mtriple=thumbv7-apple-darwin | FileCheck %s --check-prefix=THUMB
+
+define i32 @t0(i1 zeroext %a) nounwind {
+  %1 = zext i1 %a to i32
+  ret i32 %1
+}
+
+define i32 @t1(i8 signext %a) nounwind {
+  %1 = sext i8 %a to i32
+  ret i32 %1
+}
+
+define i32 @t2(i8 zeroext %a) nounwind {
+  %1 = zext i8 %a to i32
+  ret i32 %1
+}
+
+define i32 @t3(i16 signext %a) nounwind {
+  %1 = sext i16 %a to i32
+  ret i32 %1
+}
+
+define i32 @t4(i16 zeroext %a) nounwind {
+  %1 = zext i16 %a to i32
+  ret i32 %1
+}
+
+define void @foo(i8 %a, i16 %b) nounwind {
+; ARM: foo
+; THUMB: foo
+;; Materialize i1 1
+; ARM: movw r2, #1
+;; zero-ext
+; ARM: and r2, r2, #1
+; THUMB: and r2, r2, #1
+  %1 = call i32 @t0(i1 zeroext 1)
+; ARM: sxtb	r2, r1
+; ARM: mov r0, r2
+; THUMB: sxtb	r2, r1
+; THUMB: mov r0, r2
+  %2 = call i32 @t1(i8 signext %a)
+; ARM: uxtb	r2, r1
+; ARM: mov r0, r2
+; THUMB: uxtb	r2, r1
+; THUMB: mov r0, r2
+  %3 = call i32 @t2(i8 zeroext %a)
+; ARM: sxth	r2, r1
+; ARM: mov r0, r2
+; THUMB: sxth	r2, r1
+; THUMB: mov r0, r2
+  %4 = call i32 @t3(i16 signext %b)
+; ARM: uxth	r2, r1
+; ARM: mov r0, r2
+; THUMB: uxth	r2, r1
+; THUMB: mov r0, r2
+  %5 = call i32 @t4(i16 zeroext %b)
+
+;; A few test to check materialization
+;; Note: i1 1 was materialized with t1 call
+; ARM: movw r1, #255
+%6 = call i32 @t2(i8 zeroext 255)
+; ARM: movw r1, #65535
+; THUMB: movw r1, #65535
+%7 = call i32 @t4(i16 zeroext 65535)
+  ret void
+}



From chenwj at iis.sinica.edu.tw  Sat Nov  5 04:10:29 2011
From: chenwj at iis.sinica.edu.tw (=?utf-8?B?6Zmz6Z+L5Lu7?=)
Date: Sat, 5 Nov 2011 17:10:29 +0800
Subject: [llvm-commits] [PATCH][docs/GettingStarted.html] Add git imap
 config for Traditional Chinese GMail account
Message-ID: <20111105091029.GA48964@cs.nctu.edu.tw>

Hi,

  "[Gmail]/Drafts" is only for English GMail account. This patch
give an example for those developers who use Traditional Chinese
GMail account. Thanks. :)

Regards,
chenwj

-- 
Wei-Ren Chen (???)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GettingStarted.html.patch
Type: text/x-diff
Size: 415 bytes
Desc: not available
Url : http://lists.cs.uiuc.edu/pipermail/llvm-commits/attachments/20111105/668c374d/attachment.bin 

From chandlerc at gmail.com  Sat Nov  5 16:18:59 2011
From: chandlerc at gmail.com (Chandler Carruth)
Date: Sat, 05 Nov 2011 21:18:59 -0000
Subject: [llvm-commits] [llvm] r143834 - /llvm/trunk/CMakeLists.txt
Message-ID: <20111105211859.43DE92A6C12C@llvm.org>

Author: chandlerc
Date: Sat Nov  5 16:18:59 2011
New Revision: 143834

URL: http://llvm.org/viewvc/llvm-project?rev=143834&view=rev
Log:
CMake should join the party in a post 3.0 world. ;] This brings CMake's
version in-line with the configure-based version.

Modified:
    llvm/trunk/CMakeLists.txt

Modified: llvm/trunk/CMakeLists.txt
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/CMakeLists.txt?rev=143834&r1=143833&r2=143834&view=diff
==============================================================================
--- llvm/trunk/CMakeLists.txt (original)
+++ llvm/trunk/CMakeLists.txt Sat Nov  5 16:18:59 2011
@@ -10,7 +10,7 @@
   "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules"
   )
 
-set(PACKAGE_VERSION "3.0")
+set(PACKAGE_VERSION "3.1svn")
 
 set_property(GLOBAL PROPERTY USE_FOLDERS ON)
 



From tonic at nondot.org  Sat Nov  5 19:14:18 2011
From: tonic at nondot.org (Tanya Lattner)
Date: Sun, 06 Nov 2011 00:14:18 -0000
Subject: [llvm-commits] [www] r143843 - /www/trunk/devmtg/2011-11/index.html
Message-ID: <20111106001418.532912A6C12C@llvm.org>

Author: tbrethou
Date: Sat Nov  5 19:14:18 2011
New Revision: 143843

URL: http://llvm.org/viewvc/llvm-project?rev=143843&view=rev
Log:
Add talk descriptions.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143843&r1=143842&r2=143843&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 19:14:18 2011
@@ -125,6 +125,106 @@
 
 
 
+
+Integrating LLVM into FreeBSD

+Brooks Davis -  The FreeBSD Project

+The FreeBSD Project has been actively working to incorporate tools from the LLVM project into our base system including clang, libc++, and possibly lldb.  This talk will cover our efforts so far including our plans to ship FreeBSD 9.0 with clang in the base system.  I will cover both our current work to replace GPL licensed components with BSD(ish) licensed components and future or experimental work to incorporate new technologies made possible by LLVM.
+

+
+Clang MapReduce -- Automatic C++ Refactoring at Google Scale

+Chandler Carruth -  Google

+Google has over 100 million lines of code, and our biggest programming language is C++. We have a single, shared codebase developed primarily on mainline. We build every binary and all of its libraries from scratch every time, allowing us to incrementally evolve APIs and libraries over time. The entire development process is extremely incremental in nature, and even API-breaking changes are a regular occurrence. However, for core libraries used throughout the codebase, this development model is a huge challenge: how do we incrementally evolve an API in use by tens of thousands of other libraries? The answer is to use Clang to automatically refactor APIs and their users across the codebase. How do we scale Clang up to possibly the single largest unified codebase in the world? The same way Google scales anything else: MapReduce. By coupling Clang???s library design and architecture to existing Google infrastructure we can automatically compile, analyze, and refactor the ent
 ire Google codebase in minutes. In this talk, I will dive into the challenges of refactoring C++ code, how we???re using Clang and making it even better at solving them, and how we scale these solutions to the size of our codebase.
+

+
+Thread Safety Annotations in Clang

+DeLesley Hutchins -  Google

+This talk introduces the new thread safety annotations for Clang and describes the static analysis used to check them. These annotations can be used to specify properties such as whether a variable is guarded by a particular mutex, or a desired lock acquisition order.  These annotations were originally introduced in gcc, and have recently been reimplemented in Clang.
+

+ 
+Extending Clang

+Doug Gregor -  Apple

+You have an idea for the next great C(++) language feature, but how do you realize that idea? This talk will describe how to extend Clang to add new language features, from parsing and AST-construction basics to properly handling C++ templates and ensuring smooth integration into IDEs. Particular attention will be given to capturing source information in ASTs, developing bulletproof semantic analysis, and write proper regression tests to exercise the various aspects of a language feature.
+

+
+Super-optimizing LLVM IR

+Duncan Sands -  DeepBlueCapital / CNRS

+I will describe a tool to harvest expression sequences from LLVM IR and automatically discover equivalent simplified expressions. The original version of this tool only looked for sub-expressions that were equivalent to the whole, but nonetheless discovered many simplifications missed by the LLVM optimizers (most of these have now been implemented in LLVM). The tool has since been extended to a general super optimizer by Rafael Auler.
+

+
+Register Allocation in LLVM 3.0

+Jakob Olesen -  Apple

+An overview of the features in LLVM's new register allocator
+

+
+SKIR: Just-in-Time Compilation for Parallelism with LLVM

+Jeff Fifield -  University of Colorado

+The Stream and Kernel Intermediate Representation (SKIR) is a small set of LLVM intrinsics for expressing parallel computation as a graph of sequential processes (kernels) communicating over abstract data channels (streams). At runtime, programs use the SKIR intrinsics to identify functions to use as kernels, to connect kernels together using streams, and to execute resulting program graphs. Formally, the stream parallelism expressed by SKIR programs can be viewed as a generalization of Kahn process networks. More practically, we can use SKIR as a compilation target for high level languages and frameworks containing this style of program decomposition and communication. We have used SKIR to implement a compiler for the StreamIt language, to create a C++ user library for stream/data/pipeline parallel programming, and to enable parallel programming for JavaScript applications. SKIR is implemented on top of the LLVM JIT compiler and a work stealing task scheduler. We use runtim
 e compilation because of the runtime construction of program graphs, so that we can support dynamic optimization, and so that we can perform dynamic recompilation for heterogeneous targets. In this talk I will describe the SKIR intrinsics and programming model, and briefly describe high level language support that has been implemented for SKIR. I will present the compilation and optimization techniques used to transform the sequential LLVM+SKIR input code into concurrent code which can be executed in parallel using dynamic scheduling techniques. I will also describe how we can use LLVM JIT compilation to dynamically increase or decrease the amount of parallelism in a SKIR program depending on runtime hardware and application characteristics. Finally, I will describe how we can further accelerate SKIR program kernels using JIT compilation, our OpenCL backend, and GPUs.
+

+ 
+LLVM MC In Practice

+Jim Grosbach, Owen Anderson -  Apple Inc.

+Overview of projects and new developments in the LLVM MC layer, with emphasis on the MCJIT, binary analysis, ARM integrated assembler and ARM disassembler.
+

+ 
+Exporting 3D scenes from Maya to WebGL using clang and LLVM

+Jochen Wilhelmy -  Engineering consultant Wilhelmy

+Modern content creation tools such as Autodesk Maya can be seen as graphical programming language. Features like animation of attributes, embedded scripts, shading networks and vertex deformations can be translated to c++, then compiled to LLVM IR and distributed to CPU and GPU. An award winning WebGL demo is shown which was produced using this approach.
+
 
+
+DXR: Semantic Code Browsing with Clang

+Joshua  Cranmer  - Mozilla

+DXR is a source code browser which uses a clang plugin to determine information about all types, variables, and functions in a program to make reading, searching, and understanding source code easier.
+

+ 
+PTX Back-End: GPU Programming With LLVM

+Justin Holewinski -  Ohio State University

+In this talk, the PTX back-end for LLVM will be discussed, including its' past, present, and future. The current status of the back-end will be explored, with an emphasis on the portions of the LLVM IR instruction set and PTX intrinsics that are currently supported during code generation. This talk will also highlight the difficulties and issues that have been discovered while writing an LLVM back-end for a virtual ISA such as PTX, such as infinite register files. Through-out the talk, examples will be provided to highlight key features of the back-end and show preliminary performance data.
+

+In addition to back-end details, this talk will also highlight the use of Clang as a front-end for generating PTX code for NVIDIA GPUs. Through the use of Clang  and the CUDA Driver API, GPGPU programs can be developed that harness the optimization power of the LLVM compiler infrastructure. Finally, the talk will conclude with an exploration of the open issues that remain in the backend, and a discussion on how the back-end can be used within larger GPGPU compiler projects.
+

+
+Finding races and memory errors with LLVM instrumentation

+Konstantin Serebryany -  Google

+We will present two dynamic testing tools based on compile-time instrumentation, both tools use the LLVM compiler.
+
AddressSanitizer (ASan) finds memory bugs, such as use-after-free and out-of-bound accesses to heap and stack. This tool could be seen as a partial replacement for Valgrind and similar tools. The major advantages over Valgrind are the speed (less than 2x slowdown on average) and the ability to handle bugs related to stack and globals.
+
+ThreadSanitizer (TSan) finds data races. It uses the same race detection algorithm as the Valgrind-based TSan, but compile-time instrumentation allows it to be much faster (2x-4x slowdown).
+
+We will also share our experience in deploying theses testing tools in large software projects.
+
+Intel OpenCL SDK Vectorizer

+Nadav Rotem -  Intel
+In this talk, we will present our OpenCL SDK and its core technology ??? the vectorizer compiler. We plan to present an overview of our vectorizer and discuss our experience with the LLVM compiler toolkit over the last few years. We will discuss some of our design decisions and our and plans for future features (future instruction sets, vector select, predicated instructions, etc).
+

+
+Using clang in the Chromium project

+Nico Weber, Hans Wennborg -  Google

+The Chromium project is the open-source foundation on which the Google Chrome web browser is built. It is a multi-million line codebase that uses open source libraries such as WebKit, libpng, skia, ffmpeg, and leveldb. We have been able to build Chromium using clang since October 2010, and since then we've continuously expanded what we use clang for: as continuous build compiler to catch bugs with clang's superior diagnostics, with project-specific clang plugins that enforce coding-style guidelines or find domain-specific bugs in V8, and starting with Chrome 15 as production compiler on Mac OS X. We will share our experiences using clang in a mature open-source project and cover, e.g., how clang's fabled compilation speed fares in a distributed build system with 100 parallel jobs, which parts of a browser blow up when the default compiler is changed, and which of clang's warnings catch the most bugs in practice.
+

+
+Android Renderscript

+Stephen Hines -  Google

+Renderscript is Android's advanced 3D graphics rendering and compute API. It provides a portable C99-based language with extensions to facilitate common use cases for enhancing graphics and thread level parallelism. The Renderscript compiler frontend is based on Clang/LLVM. It emits a portable bitcode format for the actual compiled script code, as well as reflects a Java interface for developers to control the execution of the compiled bitcode. Executable machine code is then generated from this bitcode by an LLVM backend on the device. Renderscript is thus able to provide a mechanism by which Android developers can improve performance of their applications while retaining portability.
+

+This talk focuses on the design and implementation of Renderscript using Clang/LLVM. Renderscript leverages Clang's AST to provide a Java reflection of globally visible symbols in the compilation unit. This includes both global variables as well as invocable parameterized functions. We also transform the Clang-based AST before emitting bitcode to provide support for reference-counted types that span the Renderscript/Java memory domains. Renderscript uses bitcode as a portable code format so that we can leverage other hardware architectures in addition to the CPU in the future (GPU, DSP).
+

+Interesting facts:
+
+Difference in Clang source: 6 lines (all upstreamable with a bit of configuration logic)
+Difference in LLVM source: ~300 lines (possibly worth upstreaming, but some fixes for legacy JIT mode are no longer relevant to TOT)
+
The frontend compiler is layered completely on top of Clang, so everything we use is sub-classed and/or recombined for our purposes in the llvm-rs-cc compiler driver.
+
The backend compiler is stripped down to fit on a tablet/smartphone stack.
+
+Porting LLVM to a Next Generation DSP

+Taylor Simpson -  Qualcomm Innovation Center

+This talk will describe our experiences in porting LLVM to Qualcomm's latest generation DSP, Hexagon.  The overall experience of porting to a new architecture will be discussed. The challenges of achieving high quality code generation for a VLIW with LLVM with also be outlined.
+

+
+Polly - First successful optimizations - How to proceed?

+Tobias Grosser -  ENS/INRIA

+Polly, the LLVM Polyhedral Optimizer, was presented one year ago. At that point, only the basic infrastructure was in place and many important parts not even started. Even though Polly is still more research than production quality, we made big improvements during the last 12 months. Polly itself moved to the LLVM infrastructure with Bugtracker, Buildbot and VCS. It can now conveniently be loaded into clang as part of clang -O3. We also implemented automatic SIMD and OpenMP code generation and we created a bridge to the external PoCC optimizer. With PoCC and Polly, we were able to compile and _optimize_ the first benchmarks fully automatically and have shown significant improvements over clang -O3. In this talk we give a detailed update about the current status and want to present ideas on how to move further. These will include both research relevant ideas like automatic OpenCL code generation as well as concepts on how to develop robust loop transformations and vectorizati
 on for mainstream use.  http://polly.grosser.es
+
+
 Dinner
 Dinner attendance is capped at 140 and you must select this option during the registration process in order to attend.
 Dinner will be held after the meeting has concluded. The exact start time will be set once the meeting agenda is formalized. Dinner will be held at Il Fornaio which is within walking distance of the Marriott.



From tonic at nondot.org  Sat Nov  5 19:21:09 2011
From: tonic at nondot.org (Tanya Lattner)
Date: Sun, 06 Nov 2011 00:21:09 -0000
Subject: [llvm-commits] [www] r143844 - /www/trunk/devmtg/2011-11/index.html
Message-ID: <20111106002109.870F32A6C12C@llvm.org>

Author: tbrethou
Date: Sat Nov  5 19:21:09 2011
New Revision: 143844

URL: http://llvm.org/viewvc/llvm-project?rev=143844&view=rev
Log:
Clean up descriptions.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143844&r1=143843&r2=143844&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 19:21:09 2011
@@ -129,60 +129,71 @@
 Integrating LLVM into FreeBSD

 Brooks Davis -  The FreeBSD Project

 The FreeBSD Project has been actively working to incorporate tools from the LLVM project into our base system including clang, libc++, and possibly lldb.  This talk will cover our efforts so far including our plans to ship FreeBSD 9.0 with clang in the base system.  I will cover both our current work to replace GPL licensed components with BSD(ish) licensed components and future or experimental work to incorporate new technologies made possible by LLVM.
-

+
 
+
 Clang MapReduce -- Automatic C++ Refactoring at Google Scale

 Chandler Carruth -  Google

 Google has over 100 million lines of code, and our biggest programming language is C++. We have a single, shared codebase developed primarily on mainline. We build every binary and all of its libraries from scratch every time, allowing us to incrementally evolve APIs and libraries over time. The entire development process is extremely incremental in nature, and even API-breaking changes are a regular occurrence. However, for core libraries used throughout the codebase, this development model is a huge challenge: how do we incrementally evolve an API in use by tens of thousands of other libraries? The answer is to use Clang to automatically refactor APIs and their users across the codebase. How do we scale Clang up to possibly the single largest unified codebase in the world? The same way Google scales anything else: MapReduce. By coupling Clang???s library design and architecture to existing Google infrastructure we can automatically compile, analyze, and refactor the ent
 ire Google codebase in minutes. In this talk, I will dive into the challenges of refactoring C++ code, how we???re using Clang and making it even better at solving them, and how we scale these solutions to the size of our codebase.
-

+
 
+
 Thread Safety Annotations in Clang

 DeLesley Hutchins -  Google

 This talk introduces the new thread safety annotations for Clang and describes the static analysis used to check them. These annotations can be used to specify properties such as whether a variable is guarded by a particular mutex, or a desired lock acquisition order.  These annotations were originally introduced in gcc, and have recently been reimplemented in Clang.
-

- 
+
+
+ 
 Extending Clang

 Doug Gregor -  Apple

 You have an idea for the next great C(++) language feature, but how do you realize that idea? This talk will describe how to extend Clang to add new language features, from parsing and AST-construction basics to properly handling C++ templates and ensuring smooth integration into IDEs. Particular attention will be given to capturing source information in ASTs, developing bulletproof semantic analysis, and write proper regression tests to exercise the various aspects of a language feature.
-

+
 
+
 Super-optimizing LLVM IR

 Duncan Sands -  DeepBlueCapital / CNRS

 I will describe a tool to harvest expression sequences from LLVM IR and automatically discover equivalent simplified expressions. The original version of this tool only looked for sub-expressions that were equivalent to the whole, but nonetheless discovered many simplifications missed by the LLVM optimizers (most of these have now been implemented in LLVM). The tool has since been extended to a general super optimizer by Rafael Auler.
-

+
 
+
 Register Allocation in LLVM 3.0

 Jakob Olesen -  Apple

 An overview of the features in LLVM's new register allocator
-

+
 
+
 SKIR: Just-in-Time Compilation for Parallelism with LLVM

 Jeff Fifield -  University of Colorado

 The Stream and Kernel Intermediate Representation (SKIR) is a small set of LLVM intrinsics for expressing parallel computation as a graph of sequential processes (kernels) communicating over abstract data channels (streams). At runtime, programs use the SKIR intrinsics to identify functions to use as kernels, to connect kernels together using streams, and to execute resulting program graphs. Formally, the stream parallelism expressed by SKIR programs can be viewed as a generalization of Kahn process networks. More practically, we can use SKIR as a compilation target for high level languages and frameworks containing this style of program decomposition and communication. We have used SKIR to implement a compiler for the StreamIt language, to create a C++ user library for stream/data/pipeline parallel programming, and to enable parallel programming for JavaScript applications. SKIR is implemented on top of the LLVM JIT compiler and a work stealing task scheduler. We use runtim
 e compilation because of the runtime construction of program graphs, so that we can support dynamic optimization, and so that we can perform dynamic recompilation for heterogeneous targets. In this talk I will describe the SKIR intrinsics and programming model, and briefly describe high level language support that has been implemented for SKIR. I will present the compilation and optimization techniques used to transform the sequential LLVM+SKIR input code into concurrent code which can be executed in parallel using dynamic scheduling techniques. I will also describe how we can use LLVM JIT compilation to dynamically increase or decrease the amount of parallelism in a SKIR program depending on runtime hardware and application characteristics. Finally, I will describe how we can further accelerate SKIR program kernels using JIT compilation, our OpenCL backend, and GPUs.
-

- 
+
+
+ 
 LLVM MC In Practice

 Jim Grosbach, Owen Anderson -  Apple Inc.

 Overview of projects and new developments in the LLVM MC layer, with emphasis on the MCJIT, binary analysis, ARM integrated assembler and ARM disassembler.
-

+
  
+
 Exporting 3D scenes from Maya to WebGL using clang and LLVM

 Jochen Wilhelmy -  Engineering consultant Wilhelmy

 Modern content creation tools such as Autodesk Maya can be seen as graphical programming language. Features like animation of attributes, embedded scripts, shading networks and vertex deformations can be translated to c++, then compiled to LLVM IR and distributed to CPU and GPU. An award winning WebGL demo is shown which was produced using this approach.
-
 
+ 
 
+
 DXR: Semantic Code Browsing with Clang

 Joshua  Cranmer  - Mozilla

 DXR is a source code browser which uses a clang plugin to determine information about all types, variables, and functions in a program to make reading, searching, and understanding source code easier.
-

- 
+
+
+ 
 PTX Back-End: GPU Programming With LLVM

 Justin Holewinski -  Ohio State University

 In this talk, the PTX back-end for LLVM will be discussed, including its' past, present, and future. The current status of the back-end will be explored, with an emphasis on the portions of the LLVM IR instruction set and PTX intrinsics that are currently supported during code generation. This talk will also highlight the difficulties and issues that have been discovered while writing an LLVM back-end for a virtual ISA such as PTX, such as infinite register files. Through-out the talk, examples will be provided to highlight key features of the back-end and show preliminary performance data.
 

 In addition to back-end details, this talk will also highlight the use of Clang as a front-end for generating PTX code for NVIDIA GPUs. Through the use of Clang  and the CUDA Driver API, GPGPU programs can be developed that harness the optimization power of the LLVM compiler infrastructure. Finally, the talk will conclude with an exploration of the open issues that remain in the backend, and a discussion on how the back-end can be used within larger GPGPU compiler projects.
-

+
 
+
 Finding races and memory errors with LLVM instrumentation

 Konstantin Serebryany -  Google

 We will present two dynamic testing tools based on compile-time instrumentation, both tools use the LLVM compiler.
@@ -191,17 +202,21 @@
 ThreadSanitizer (TSan) finds data races. It uses the same race detection algorithm as the Valgrind-based TSan, but compile-time instrumentation allows it to be much faster (2x-4x slowdown).
 
 We will also share our experience in deploying theses testing tools in large software projects.
+
 
+
 Intel OpenCL SDK Vectorizer

 Nadav Rotem -  Intel
 In this talk, we will present our OpenCL SDK and its core technology ??? the vectorizer compiler. We plan to present an overview of our vectorizer and discuss our experience with the LLVM compiler toolkit over the last few years. We will discuss some of our design decisions and our and plans for future features (future instruction sets, vector select, predicated instructions, etc).
-

+
 
+
 Using clang in the Chromium project

 Nico Weber, Hans Wennborg -  Google

 The Chromium project is the open-source foundation on which the Google Chrome web browser is built. It is a multi-million line codebase that uses open source libraries such as WebKit, libpng, skia, ffmpeg, and leveldb. We have been able to build Chromium using clang since October 2010, and since then we've continuously expanded what we use clang for: as continuous build compiler to catch bugs with clang's superior diagnostics, with project-specific clang plugins that enforce coding-style guidelines or find domain-specific bugs in V8, and starting with Chrome 15 as production compiler on Mac OS X. We will share our experiences using clang in a mature open-source project and cover, e.g., how clang's fabled compilation speed fares in a distributed build system with 100 parallel jobs, which parts of a browser blow up when the default compiler is changed, and which of clang's warnings catch the most bugs in practice.
-

+
 
+
 Android Renderscript

 Stephen Hines -  Google

 Renderscript is Android's advanced 3D graphics rendering and compute API. It provides a portable C99-based language with extensions to facilitate common use cases for enhancing graphics and thread level parallelism. The Renderscript compiler frontend is based on Clang/LLVM. It emits a portable bitcode format for the actual compiled script code, as well as reflects a Java interface for developers to control the execution of the compiled bitcode. Executable machine code is then generated from this bitcode by an LLVM backend on the device. Renderscript is thus able to provide a mechanism by which Android developers can improve performance of their applications while retaining portability.
@@ -211,15 +226,18 @@
 Interesting facts:
 

 Difference in Clang source: 6 lines (all upstreamable with a bit of configuration logic)
-Difference in LLVM source: ~300 lines (possibly worth upstreaming, but some fixes for legacy JIT mode are no longer relevant to TOT)
-
The frontend compiler is layered completely on top of Clang, so everything we use is sub-classed and/or recombined for our purposes in the llvm-rs-cc compiler driver.
-
The backend compiler is stripped down to fit on a tablet/smartphone stack.
+
Difference in LLVM source: ~300 lines (possibly worth upstreaming, but some fixes for legacy JIT mode are no longer relevant to TOT)
+The frontend compiler is layered completely on top of Clang, so everything we use is sub-classed and/or recombined for our purposes in the llvm-rs-cc compiler driver.
+The backend compiler is stripped down to fit on a tablet/smartphone stack.
+

 
+
 Porting LLVM to a Next Generation DSP

 Taylor Simpson -  Qualcomm Innovation Center

 This talk will describe our experiences in porting LLVM to Qualcomm's latest generation DSP, Hexagon.  The overall experience of porting to a new architecture will be discussed. The challenges of achieving high quality code generation for a VLIW with LLVM with also be outlined.
-

+
 
+
 Polly - First successful optimizations - How to proceed?

 Tobias Grosser -  ENS/INRIA

 Polly, the LLVM Polyhedral Optimizer, was presented one year ago. At that point, only the basic infrastructure was in place and many important parts not even started. Even though Polly is still more research than production quality, we made big improvements during the last 12 months. Polly itself moved to the LLVM infrastructure with Bugtracker, Buildbot and VCS. It can now conveniently be loaded into clang as part of clang -O3. We also implemented automatic SIMD and OpenMP code generation and we created a bridge to the external PoCC optimizer. With PoCC and Polly, we were able to compile and _optimize_ the first benchmarks fully automatically and have shown significant improvements over clang -O3. In this talk we give a detailed update about the current status and want to present ideas on how to move further. These will include both research relevant ideas like automatic OpenCL code generation as well as concepts on how to develop robust loop transformations and vectorizati
 on for mainstream use.  http://polly.grosser.es



From tonic at nondot.org  Sat Nov  5 19:39:32 2011
From: tonic at nondot.org (Tanya Lattner)
Date: Sun, 06 Nov 2011 00:39:32 -0000
Subject: [llvm-commits] [www] r143845 - /www/trunk/devmtg/2011-11/index.html
Message-ID: <20111106003932.280502A6C12C@llvm.org>

Author: tbrethou
Date: Sat Nov  5 19:39:31 2011
New Revision: 143845

URL: http://llvm.org/viewvc/llvm-project?rev=143845&view=rev
Log:
Add links for talks.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143845&r1=143844&r2=143845&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 19:39:31 2011
@@ -83,41 +83,41 @@
 
 9:00 - 9:20Welcome
Chris Lattner, Apple Inc.Main Hall
 
-9:20 - 10:05Integrating LLVM into FreeBSD
Brooks Davis, The FreeBSD ProjectMain Hall
-Intel OpenCL SDK Vectorizer
Nadav Rotem, IntelSecond Hall
+9:20 - 10:05Integrating LLVM into FreeBSD
Brooks Davis, The FreeBSD ProjectMain Hall
+Intel OpenCL SDK Vectorizer
Nadav Rotem, IntelSecond Hall
 
-10:05 - 10:50Clang MapReduce -- Automatic C++ Refactoring at Google Scale
Chandler Carruth, GoogleMain Hall
-PTX Back-End: GPU Programming With LLVM
Justin Holewinski, Ohio StateSecond Hall
+10:05 - 10:50Clang MapReduce -- Automatic C++ Refactoring at Google Scale
Chandler Carruth, GoogleMain Hall
+PTX Back-End: GPU Programming With LLVM
Justin Holewinski, Ohio StateSecond Hall
 Improving LLVM Testing BOF
David BlaikieTBD
 
 10:50 - 11:05BreakTBD
 
-11:05 - 11:50Extending Clang
Doug Gregor, Apple Inc.Main Hall
-Porting LLVM to a Next Generation DSP 
Taylor Simpson, QuICSecond Hall
+11:05 - 11:50Extending Clang
Doug Gregor, Apple Inc.Main Hall
+Porting LLVM to a Next Generation DSP
Taylor Simpson, QuICSecond Hall
 
-11:50 - 12:35DXR: Semantic Code Browsing with Clang
Joshua Cranmer, MozillaMain Hall
-LLVM MC In Practice
Jim Grosbach, Owen Anderson Apple Inc.Second Hall
+11:50 - 12:35DXR: Semantic Code Browsing with Clang
Joshua Cranmer, MozillaMain Hall
+LLVM MC In Practice
Jim Grosbach, Owen Anderson Apple Inc.Second Hall
 
 12:35 - 1:35LunchTBD
 
-1:35 - 2:20Using clang in the Chromium project
Nico Weber, Hans Wennborg, GoogleMain Hall
-Polly - First successful optimizations - How to proceed?
Tobias Grosser, ENS/INRIASecond Hall
+1:35 - 2:20Using clang in the Chromium project
Nico Weber, Hans Wennborg, GoogleMain Hall
+Polly - First successful optimizations - How to proceed?
Tobias Grosser, ENS/INRIASecond Hall
 MC Linkers BOF
Luba Tang, MediatekTBD
 
-2:20 - 3:05Android Renderscript
Stephen Hines, GoogleMain Hall
-SKIR: Just-in-Time Compilation for Parallelism with LLVM
Jeff Fifield, University of ColoradoSecond Hall
+2:20 - 3:05Android Renderscript
Stephen Hines, GoogleMain Hall
+SKIR: Just-in-Time Compilation for Parallelism with LLVM
Jeff Fifield, University of ColoradoSecond Hall
 Improving the Clang Driver BOF
James Molloy, ARMTBD
 
 3:05 - 3:45PostersTBD
 
-3:45 - 4:30Register Allocation in LLVM 3.0 
Jakob Olesen, AppleMain Hall
-Exporting 3D scenes from Maya to WebGL using clang and LLVM
Jochen Wilhelmy, consultantSecond Hall
+3:45 - 4:30Register Allocation in LLVM 3.0
Jakob Olesen, AppleMain Hall
+Exporting 3D scenes from Maya to WebGL using clang and LLVM
Jochen Wilhelmy, consultantSecond Hall
 
-4:30 - 5:15Super-optimizing LLVM IR
Duncan Sands, DeepBlueCapitalMain Hall
-Finding races and memory errors with LLVM instrumentation 
Konstantin Serebryany, GoogleSecond Hall
+4:30 - 5:15Super-optimizing LLVM IR
Duncan Sands, DeepBlueCapitalMain Hall
+Finding races and memory errors with LLVM instrumentation
Konstantin Serebryany, GoogleSecond Hall
 Bitcode Portability/Versioning BOF
Stephen Hines, David Sehr, GoogleTBD
 
-4:30 - 5:10Thread Safety Annotations in Clang
DeLesley Hutchins, GoogleMain Hall
+4:30 - 5:10Thread Safety Annotations in Clang
DeLesley Hutchins, GoogleMain Hall
 Backend/Infrastructure Super BoF
Jim Grosbach, Apple Inc.Second Hall
 Community Event Planning
David Kipping, QualcommTBD
 
@@ -126,67 +126,67 @@
 
 
 
-Integrating LLVM into FreeBSD

+Integrating LLVM into FreeBSD

 Brooks Davis -  The FreeBSD Project

 The FreeBSD Project has been actively working to incorporate tools from the LLVM project into our base system including clang, libc++, and possibly lldb.  This talk will cover our efforts so far including our plans to ship FreeBSD 9.0 with clang in the base system.  I will cover both our current work to replace GPL licensed components with BSD(ish) licensed components and future or experimental work to incorporate new technologies made possible by LLVM.
 
 
 
-Clang MapReduce -- Automatic C++ Refactoring at Google Scale

+Clang MapReduce -- Automatic C++ Refactoring at Google Scale

 Chandler Carruth -  Google

 Google has over 100 million lines of code, and our biggest programming language is C++. We have a single, shared codebase developed primarily on mainline. We build every binary and all of its libraries from scratch every time, allowing us to incrementally evolve APIs and libraries over time. The entire development process is extremely incremental in nature, and even API-breaking changes are a regular occurrence. However, for core libraries used throughout the codebase, this development model is a huge challenge: how do we incrementally evolve an API in use by tens of thousands of other libraries? The answer is to use Clang to automatically refactor APIs and their users across the codebase. How do we scale Clang up to possibly the single largest unified codebase in the world? The same way Google scales anything else: MapReduce. By coupling Clang???s library design and architecture to existing Google infrastructure we can automatically compile, analyze, and refactor the ent
 ire Google codebase in minutes. In this talk, I will dive into the challenges of refactoring C++ code, how we???re using Clang and making it even better at solving them, and how we scale these solutions to the size of our codebase.
 
 
 
-Thread Safety Annotations in Clang

+Thread Safety Annotations in Clang

 DeLesley Hutchins -  Google

 This talk introduces the new thread safety annotations for Clang and describes the static analysis used to check them. These annotations can be used to specify properties such as whether a variable is guarded by a particular mutex, or a desired lock acquisition order.  These annotations were originally introduced in gcc, and have recently been reimplemented in Clang.
 
 
  
-Extending Clang

+Extending Clang

 Doug Gregor -  Apple

 You have an idea for the next great C(++) language feature, but how do you realize that idea? This talk will describe how to extend Clang to add new language features, from parsing and AST-construction basics to properly handling C++ templates and ensuring smooth integration into IDEs. Particular attention will be given to capturing source information in ASTs, developing bulletproof semantic analysis, and write proper regression tests to exercise the various aspects of a language feature.
 
 
 
-Super-optimizing LLVM IR

+Super-optimizing LLVM IR

 Duncan Sands -  DeepBlueCapital / CNRS

 I will describe a tool to harvest expression sequences from LLVM IR and automatically discover equivalent simplified expressions. The original version of this tool only looked for sub-expressions that were equivalent to the whole, but nonetheless discovered many simplifications missed by the LLVM optimizers (most of these have now been implemented in LLVM). The tool has since been extended to a general super optimizer by Rafael Auler.
 
 
 
-Register Allocation in LLVM 3.0

+Register Allocation in LLVM 3.0

 Jakob Olesen -  Apple

 An overview of the features in LLVM's new register allocator
 
 
 
-SKIR: Just-in-Time Compilation for Parallelism with LLVM

+SKIR: Just-in-Time Compilation for Parallelism with LLVM

 Jeff Fifield -  University of Colorado

 The Stream and Kernel Intermediate Representation (SKIR) is a small set of LLVM intrinsics for expressing parallel computation as a graph of sequential processes (kernels) communicating over abstract data channels (streams). At runtime, programs use the SKIR intrinsics to identify functions to use as kernels, to connect kernels together using streams, and to execute resulting program graphs. Formally, the stream parallelism expressed by SKIR programs can be viewed as a generalization of Kahn process networks. More practically, we can use SKIR as a compilation target for high level languages and frameworks containing this style of program decomposition and communication. We have used SKIR to implement a compiler for the StreamIt language, to create a C++ user library for stream/data/pipeline parallel programming, and to enable parallel programming for JavaScript applications. SKIR is implemented on top of the LLVM JIT compiler and a work stealing task scheduler. We use runtim
 e compilation because of the runtime construction of program graphs, so that we can support dynamic optimization, and so that we can perform dynamic recompilation for heterogeneous targets. In this talk I will describe the SKIR intrinsics and programming model, and briefly describe high level language support that has been implemented for SKIR. I will present the compilation and optimization techniques used to transform the sequential LLVM+SKIR input code into concurrent code which can be executed in parallel using dynamic scheduling techniques. I will also describe how we can use LLVM JIT compilation to dynamically increase or decrease the amount of parallelism in a SKIR program depending on runtime hardware and application characteristics. Finally, I will describe how we can further accelerate SKIR program kernels using JIT compilation, our OpenCL backend, and GPUs.
 
 
  
-LLVM MC In Practice

+LLVM MC In Practice

 Jim Grosbach, Owen Anderson -  Apple Inc.

 Overview of projects and new developments in the LLVM MC layer, with emphasis on the MCJIT, binary analysis, ARM integrated assembler and ARM disassembler.
 
  
 
-Exporting 3D scenes from Maya to WebGL using clang and LLVM

+Exporting 3D scenes from Maya to WebGL using clang and LLVM

 Jochen Wilhelmy -  Engineering consultant Wilhelmy

 Modern content creation tools such as Autodesk Maya can be seen as graphical programming language. Features like animation of attributes, embedded scripts, shading networks and vertex deformations can be translated to c++, then compiled to LLVM IR and distributed to CPU and GPU. An award winning WebGL demo is shown which was produced using this approach.
  
 
 
-DXR: Semantic Code Browsing with Clang

+DXR: Semantic Code Browsing with Clang

 Joshua  Cranmer  - Mozilla

 DXR is a source code browser which uses a clang plugin to determine information about all types, variables, and functions in a program to make reading, searching, and understanding source code easier.
 
 
  
-PTX Back-End: GPU Programming With LLVM

+PTX Back-End: GPU Programming With LLVM

 Justin Holewinski -  Ohio State University

 In this talk, the PTX back-end for LLVM will be discussed, including its' past, present, and future. The current status of the back-end will be explored, with an emphasis on the portions of the LLVM IR instruction set and PTX intrinsics that are currently supported during code generation. This talk will also highlight the difficulties and issues that have been discovered while writing an LLVM back-end for a virtual ISA such as PTX, such as infinite register files. Through-out the talk, examples will be provided to highlight key features of the back-end and show preliminary performance data.
 

@@ -194,7 +194,7 @@
 
 
 
-Finding races and memory errors with LLVM instrumentation

+Finding races and memory errors with LLVM instrumentation

 Konstantin Serebryany -  Google

 We will present two dynamic testing tools based on compile-time instrumentation, both tools use the LLVM compiler.
 
AddressSanitizer (ASan) finds memory bugs, such as use-after-free and out-of-bound accesses to heap and stack. This tool could be seen as a partial replacement for Valgrind and similar tools. The major advantages over Valgrind are the speed (less than 2x slowdown on average) and the ability to handle bugs related to stack and globals.
@@ -205,19 +205,19 @@
 
 
 
-Intel OpenCL SDK Vectorizer

+Intel OpenCL SDK Vectorizer

 Nadav Rotem -  Intel
 In this talk, we will present our OpenCL SDK and its core technology ??? the vectorizer compiler. We plan to present an overview of our vectorizer and discuss our experience with the LLVM compiler toolkit over the last few years. We will discuss some of our design decisions and our and plans for future features (future instruction sets, vector select, predicated instructions, etc).
 
 
 
-Using clang in the Chromium project

+Using clang in the Chromium project

 Nico Weber, Hans Wennborg -  Google

 The Chromium project is the open-source foundation on which the Google Chrome web browser is built. It is a multi-million line codebase that uses open source libraries such as WebKit, libpng, skia, ffmpeg, and leveldb. We have been able to build Chromium using clang since October 2010, and since then we've continuously expanded what we use clang for: as continuous build compiler to catch bugs with clang's superior diagnostics, with project-specific clang plugins that enforce coding-style guidelines or find domain-specific bugs in V8, and starting with Chrome 15 as production compiler on Mac OS X. We will share our experiences using clang in a mature open-source project and cover, e.g., how clang's fabled compilation speed fares in a distributed build system with 100 parallel jobs, which parts of a browser blow up when the default compiler is changed, and which of clang's warnings catch the most bugs in practice.
 
 
 
-Android Renderscript

+Android Renderscript

 Stephen Hines -  Google

 Renderscript is Android's advanced 3D graphics rendering and compute API. It provides a portable C99-based language with extensions to facilitate common use cases for enhancing graphics and thread level parallelism. The Renderscript compiler frontend is based on Clang/LLVM. It emits a portable bitcode format for the actual compiled script code, as well as reflects a Java interface for developers to control the execution of the compiled bitcode. Executable machine code is then generated from this bitcode by an LLVM backend on the device. Renderscript is thus able to provide a mechanism by which Android developers can improve performance of their applications while retaining portability.
 

@@ -232,13 +232,13 @@
 

 
 
-Porting LLVM to a Next Generation DSP

+Porting LLVM to a Next Generation DSP

 Taylor Simpson -  Qualcomm Innovation Center

 This talk will describe our experiences in porting LLVM to Qualcomm's latest generation DSP, Hexagon.  The overall experience of porting to a new architecture will be discussed. The challenges of achieving high quality code generation for a VLIW with LLVM with also be outlined.
 
 
 
-Polly - First successful optimizations - How to proceed?

+Polly - First successful optimizations - How to proceed?

 Tobias Grosser -  ENS/INRIA

 Polly, the LLVM Polyhedral Optimizer, was presented one year ago. At that point, only the basic infrastructure was in place and many important parts not even started. Even though Polly is still more research than production quality, we made big improvements during the last 12 months. Polly itself moved to the LLVM infrastructure with Bugtracker, Buildbot and VCS. It can now conveniently be loaded into clang as part of clang -O3. We also implemented automatic SIMD and OpenMP code generation and we created a bridge to the external PoCC optimizer. With PoCC and Polly, we were able to compile and _optimize_ the first benchmarks fully automatically and have shown significant improvements over clang -O3. In this talk we give a detailed update about the current status and want to present ideas on how to move further. These will include both research relevant ideas like automatic OpenCL code generation as well as concepts on how to develop robust loop transformations and vectorizati
 on for mainstream use.  http://polly.grosser.es
 



From tonic at nondot.org  Sat Nov  5 19:41:17 2011
From: tonic at nondot.org (Tanya Lattner)
Date: Sun, 06 Nov 2011 00:41:17 -0000
Subject: [llvm-commits] [www] r143847 - /www/trunk/devmtg/2011-11/index.html
Message-ID: <20111106004117.0DE612A6C12C@llvm.org>

Author: tbrethou
Date: Sat Nov  5 19:41:16 2011
New Revision: 143847

URL: http://llvm.org/viewvc/llvm-project?rev=143847&view=rev
Log:
Fix a couple links.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143847&r1=143846&r2=143847&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 19:41:16 2011
@@ -95,7 +95,7 @@
 11:05 - 11:50Extending Clang
Doug Gregor, Apple Inc.Main Hall
 Porting LLVM to a Next Generation DSP
Taylor Simpson, QuICSecond Hall
 
-11:50 - 12:35DXR: Semantic Code Browsing with Clang
Joshua Cranmer, MozillaMain Hall
+11:50 - 12:35DXR: Semantic Code Browsing with Clang
Joshua Cranmer, MozillaMain Hall
 LLVM MC In Practice
Jim Grosbach, Owen Anderson Apple Inc.Second Hall
 
 12:35 - 1:35LunchTBD
@@ -104,7 +104,7 @@
 Polly - First successful optimizations - How to proceed?
Tobias Grosser, ENS/INRIASecond Hall
 MC Linkers BOF
Luba Tang, MediatekTBD
 
-2:20 - 3:05Android Renderscript
Stephen Hines, GoogleMain Hall
+2:20 - 3:05Android Renderscript
Stephen Hines, GoogleMain Hall
 SKIR: Just-in-Time Compilation for Parallelism with LLVM
Jeff Fifield, University of ColoradoSecond Hall
 Improving the Clang Driver BOF
James Molloy, ARMTBD
 



From tonic at nondot.org  Sat Nov  5 19:42:36 2011
From: tonic at nondot.org (Tanya Lattner)
Date: Sun, 06 Nov 2011 00:42:36 -0000
Subject: [llvm-commits] [www] r143848 - /www/trunk/devmtg/2011-11/index.html
Message-ID: <20111106004236.541462A6C12C@llvm.org>

Author: tbrethou
Date: Sat Nov  5 19:42:36 2011
New Revision: 143848

URL: http://llvm.org/viewvc/llvm-project?rev=143848&view=rev
Log:
Add sponsor.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143848&r1=143847&r2=143848&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 19:42:36 2011
@@ -21,7 +21,7 @@
 
 
 
-
SPONSORED BY: QuIC, Apple

+
SPONSORED BY: QuIC, Apple
,Google
 
 We are eager to find companies to help cover travel expenses for speakers needing assistance. If your company is interested, please contact dkipping at qualcomm.com.
 



From tonic at nondot.org  Sat Nov  5 19:43:20 2011
From: tonic at nondot.org (Tanya Lattner)
Date: Sun, 06 Nov 2011 00:43:20 -0000
Subject: [llvm-commits] [www] r143849 - /www/trunk/devmtg/2011-11/index.html
Message-ID: <20111106004320.10D3D2A6C12C@llvm.org>

Author: tbrethou
Date: Sat Nov  5 19:43:19 2011
New Revision: 143849

URL: http://llvm.org/viewvc/llvm-project?rev=143849&view=rev
Log:
Fix sponsor header.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143849&r1=143848&r2=143849&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 19:43:19 2011
@@ -21,7 +21,7 @@
 
 
 
-
SPONSORED BY: QuIC, Apple
,Google
+
SPONSORED BY: QuIC, Apple,Google

 
 We are eager to find companies to help cover travel expenses for speakers needing assistance. If your company is interested, please contact dkipping at qualcomm.com.
 



From tonic at nondot.org  Sat Nov  5 19:44:11 2011
From: tonic at nondot.org (Tanya Lattner)
Date: Sun, 06 Nov 2011 00:44:11 -0000
Subject: [llvm-commits] [www] r143850 - /www/trunk/devmtg/2011-11/index.html
Message-ID: <20111106004411.BB5B72A6C12C@llvm.org>

Author: tbrethou
Date: Sat Nov  5 19:44:11 2011
New Revision: 143850

URL: http://llvm.org/viewvc/llvm-project?rev=143850&view=rev
Log:
Add space.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143850&r1=143849&r2=143850&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 19:44:11 2011
@@ -21,7 +21,7 @@
 
 
 
-
SPONSORED BY: QuIC, Apple,Google

+
SPONSORED BY: QuIC, Apple, Google

 
 We are eager to find companies to help cover travel expenses for speakers needing assistance. If your company is interested, please contact dkipping at qualcomm.com.
 



From tonic at nondot.org  Sat Nov  5 19:53:07 2011
From: tonic at nondot.org (Tanya Lattner)
Date: Sun, 06 Nov 2011 00:53:07 -0000
Subject: [llvm-commits] [www] r143851 - /www/trunk/devmtg/2011-11/index.html
Message-ID: <20111106005307.393202A6C12C@llvm.org>

Author: tbrethou
Date: Sat Nov  5 19:53:06 2011
New Revision: 143851

URL: http://llvm.org/viewvc/llvm-project?rev=143851&view=rev
Log:
Update session time.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143851&r1=143850&r2=143851&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 19:53:06 2011
@@ -117,7 +117,7 @@
 Finding races and memory errors with LLVM instrumentation
Konstantin Serebryany, GoogleSecond Hall
 Bitcode Portability/Versioning BOF
Stephen Hines, David Sehr, GoogleTBD
 
-4:30 - 5:10Thread Safety Annotations in Clang
DeLesley Hutchins, GoogleMain Hall
+5:15 - 6:00Thread Safety Annotations in Clang
DeLesley Hutchins, GoogleMain Hall
 Backend/Infrastructure Super BoF
Jim Grosbach, Apple Inc.Second Hall
 Community Event Planning
David Kipping, QualcommTBD
 



From tonic at nondot.org  Sat Nov  5 20:08:36 2011
From: tonic at nondot.org (Tanya Lattner)
Date: Sun, 06 Nov 2011 01:08:36 -0000
Subject: [llvm-commits] [www] r143852 - /www/trunk/devmtg/2011-11/index.html
Message-ID: <20111106010836.5F9A02A6C12C@llvm.org>

Author: tbrethou
Date: Sat Nov  5 20:08:36 2011
New Revision: 143852

URL: http://llvm.org/viewvc/llvm-project?rev=143852&view=rev
Log:
Add poster sessions.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143852&r1=143851&r2=143852&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 20:08:36 2011
@@ -8,6 +8,8 @@
         Funding Assistance
         Location
 	Agenda
+        Talk Abstracts
+        Poster Abstracts
         Dinner
 
 
@@ -108,7 +110,11 @@
 SKIR: Just-in-Time Compilation for Parallelism with LLVM
Jeff Fifield, University of ColoradoSecond Hall
 Improving the Clang Driver BOF
James Molloy, ARMTBD
 
-3:05 - 3:45PostersTBD
+3:05 - 3:45PostersTBD
+LunarGLASS: A LLVM-based shader compiler stack
Michael Ilseman, LunarGTBD
+Symbolic Testing of OpenCL Code
Peter Collingbourne, Imperial College LondonTBD
+Code verification based on attributes annotation - Implementing custom attributes check using Clang
Michael Han, AutodeskTBD
+Parfait - A Scalable Static Bug-Checking Tool Built on LLVM
Cristina Cifuentes, Nathan Keynes, Andrew Craik, Lian Li, Nathan Hawes, Andrew Browne, and Manuel Valdiviezo, Oracle LabsTBD
 
 3:45 - 4:30Register Allocation in LLVM 3.0
Jakob Olesen, AppleMain Hall
 Exporting 3D scenes from Maya to WebGL using clang and LLVM
Jochen Wilhelmy, consultantSecond Hall
@@ -125,6 +131,7 @@
 
 
 
+Talk Abstracts
 
 Integrating LLVM into FreeBSD

 Brooks Davis -  The FreeBSD Project

@@ -243,6 +250,44 @@
 Polly, the LLVM Polyhedral Optimizer, was presented one year ago. At that point, only the basic infrastructure was in place and many important parts not even started. Even though Polly is still more research than production quality, we made big improvements during the last 12 months. Polly itself moved to the LLVM infrastructure with Bugtracker, Buildbot and VCS. It can now conveniently be loaded into clang as part of clang -O3. We also implemented automatic SIMD and OpenMP code generation and we created a bridge to the external PoCC optimizer. With PoCC and Polly, we were able to compile and _optimize_ the first benchmarks fully automatically and have shown significant improvements over clang -O3. In this talk we give a detailed update about the current status and want to present ideas on how to move further. These will include both research relevant ideas like automatic OpenCL code generation as well as concepts on how to develop robust loop transformations and vectorizati
 on for mainstream use.  http://polly.grosser.es
 
 
+
+Poster Abstracts
+
+Parfait - A Scalable Static Bug-Checking Tool Built on LLVM
       
+Cristina Cifuentes, Nathan Keynes, Andrew Craik, Lian Li, Nathan Hawes, Andrew Browne, and Manuel Valdiviezo   - Oracle Labs

+Parfait is a static bug-checking tool for C/C++ applications built on the LLVM framework. Parfait achieves precision and scalability at the same time by employing a layered program analysis framework. In Parfait, different analyses varying in precision and runtime expense are invoked on demand to detect defects of a specific type, effectively achieving higher precision with smaller runtime overheads.
+

+Parfait has been deployed into several development organizations within Oracle. It is being run over millions of lines of C and C++ code on a daily basis. Parfait is currently processing code written for a variety of different platforms including:
+

+      Oracle Solaris Studio on Solaris
+     Microsoft Visual C/C++ on Windows (excluding MFC headers)
+     GCC on Linux
+     Intel C/C++ Compiler on Linux
+
+
+Despite the size and complexity of the code bases being analyzed, the Parfait false-positive rate has remained below 10%.
+
>
+This poster will present the design of the Parfait tool, summarize our experience with the LLVM infrastructure, and present more comprehensive results than the preliminary results we first presented to the LLVM community at the LLVM Developers Conference in 2009.
+
+
+
+Code verification based on attributes annotation - Implementing custom attributes check using Clang

+Michael Han  - Autodesk   

+Introduce a tool named "Hippocrates" we developed at Autodesk based on Clang's attribute system to help engineers verify functions being behaved as designed. The talk will focus on the motivation and goal of the tool, how we hacked Clang (would be a very high level 1000 feet overview due to time limits), and some results of using the tool on our large code base like Autodesk Maya with millions of lines C++ code.
+
+
+
+LunarGLASS: A LLVM-based shader compiler stack

+Michael Ilseman   - LunarG  

+LunarGLASS is an LLVM-based shader compiler stack. It brings a new approach to shader compilation by splitting the common shared intermediate representation (IR) into two levels; the top level is completely platform independent while the bottom level is dynamically tailorable to different families of architecture.  http://www.lunarglass.org/documentation
+

+
+
+Symbolic Testing of OpenCL Code

+Peter Collingbourne  - Imperial College London  

+The poster will describe our research on the subject of verification of OpenCL kernels using symbolic execution. We present an effective technique for crosschecking a C program against an accelerated OpenCL version, as well as a technique for detecting data races in OpenCL programs. Our techniques are implemented in KLEE-CL, a symbolic execution engine based on KLEE and KLEE-FP that supports symbolic reasoning on the equivalence between symbolic values. Our approach is to symbolically model the OpenCL environment using an OpenCL runtime library targeted to symbolic execution. Using this model we are able to run OpenCL programs symbolically, keeping track of memory accesses for the purpose of race detection. We then compare the symbolic result against the plain C program in order to detect mismatches between the two versions. We applied KLEE-CL to the Parboil benchmark suite, the Bullet physics library and the OP2 library, in which we were able to find a total of seven errors
 : three mismatches between the OpenCL and C implementations, two memory errors, one OpenCL compiler bug and one race condition.
+

+
 Dinner
 Dinner attendance is capped at 140 and you must select this option during the registration process in order to attend.
 Dinner will be held after the meeting has concluded. The exact start time will be set once the meeting agenda is formalized. Dinner will be held at Il Fornaio which is within walking distance of the Marriott.



From tonic at nondot.org  Sat Nov  5 20:10:07 2011
From: tonic at nondot.org (Tanya Lattner)
Date: Sun, 06 Nov 2011 01:10:07 -0000
Subject: [llvm-commits] [www] r143853 - /www/trunk/devmtg/2011-11/index.html
Message-ID: <20111106011007.CD66F2A6C12C@llvm.org>

Author: tbrethou
Date: Sat Nov  5 20:10:07 2011
New Revision: 143853

URL: http://llvm.org/viewvc/llvm-project?rev=143853&view=rev
Log:
Fix poster title.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143853&r1=143852&r2=143853&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 20:10:07 2011
@@ -250,8 +250,7 @@
 Polly, the LLVM Polyhedral Optimizer, was presented one year ago. At that point, only the basic infrastructure was in place and many important parts not even started. Even though Polly is still more research than production quality, we made big improvements during the last 12 months. Polly itself moved to the LLVM infrastructure with Bugtracker, Buildbot and VCS. It can now conveniently be loaded into clang as part of clang -O3. We also implemented automatic SIMD and OpenMP code generation and we created a bridge to the external PoCC optimizer. With PoCC and Polly, we were able to compile and _optimize_ the first benchmarks fully automatically and have shown significant improvements over clang -O3. In this talk we give a detailed update about the current status and want to present ideas on how to move further. These will include both research relevant ideas like automatic OpenCL code generation as well as concepts on how to develop robust loop transformations and vectorizati
 on for mainstream use.  http://polly.grosser.es
 
 
-
-Poster Abstracts
+Poster Abstracts
 
 Parfait - A Scalable Static Bug-Checking Tool Built on LLVM
       
 Cristina Cifuentes, Nathan Keynes, Andrew Craik, Lian Li, Nathan Hawes, Andrew Browne, and Manuel Valdiviezo   - Oracle Labs




From tonic at nondot.org  Sat Nov  5 20:11:53 2011
From: tonic at nondot.org (Tanya Lattner)
Date: Sun, 06 Nov 2011 01:11:53 -0000
Subject: [llvm-commits] [www] r143854 - /www/trunk/devmtg/2011-11/index.html
Message-ID: <20111106011153.D48D72A6C12C@llvm.org>

Author: tbrethou
Date: Sat Nov  5 20:11:53 2011
New Revision: 143854

URL: http://llvm.org/viewvc/llvm-project?rev=143854&view=rev
Log:
Increase rowspan for posters.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143854&r1=143853&r2=143854&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 20:11:53 2011
@@ -110,7 +110,7 @@
 SKIR: Just-in-Time Compilation for Parallelism with LLVM
Jeff Fifield, University of ColoradoSecond Hall
 Improving the Clang Driver BOF
James Molloy, ARMTBD
 
-3:05 - 3:45PostersTBD
+3:05 - 3:45PostersTBD
 LunarGLASS: A LLVM-based shader compiler stack
Michael Ilseman, LunarGTBD
 Symbolic Testing of OpenCL Code
Peter Collingbourne, Imperial College LondonTBD
 Code verification based on attributes annotation - Implementing custom attributes check using Clang
Michael Han, AutodeskTBD
@@ -265,7 +265,7 @@
 
 
 Despite the size and complexity of the code bases being analyzed, the Parfait false-positive rate has remained below 10%.
-
>
+

 This poster will present the design of the Parfait tool, summarize our experience with the LLVM infrastructure, and present more comprehensive results than the preliminary results we first presented to the LLVM community at the LLVM Developers Conference in 2009.
 
 



From nicholas at mxc.ca  Sat Nov  5 20:41:01 2011
From: nicholas at mxc.ca (Nick Lewycky)
Date: Sun, 06 Nov 2011 01:41:01 -0000
Subject: [llvm-commits] [www] r143855 - /www/trunk/devmtg/2011-11/index.html
Message-ID: <20111106014101.63C342A6C12C@llvm.org>

Author: nicholas
Date: Sat Nov  5 20:41:01 2011
New Revision: 143855

URL: http://llvm.org/viewvc/llvm-project?rev=143855&view=rev
Log:
Fix two formatting errors; remove broken  tag causing an extra indent for
the remainder of the page, and add a line break after the byline for Nadav's
talk.

Modified:
    www/trunk/devmtg/2011-11/index.html

Modified: www/trunk/devmtg/2011-11/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/devmtg/2011-11/index.html?rev=143855&r1=143854&r2=143855&view=diff
==============================================================================
--- www/trunk/devmtg/2011-11/index.html (original)
+++ www/trunk/devmtg/2011-11/index.html Sat Nov  5 20:41:01 2011
@@ -206,14 +206,14 @@
 We will present two dynamic testing tools based on compile-time instrumentation, both tools use the LLVM compiler.
 AddressSanitizer (ASan) finds memory bugs, such as use-after-free and out-of-bound accesses to heap and stack. This tool could be seen as a partial replacement for Valgrind and similar tools. The major advantages over Valgrind are the speed (less than 2x slowdown on average) and the ability to handle bugs related to stack and globals.
 
-ThreadSanitizer (TSan) finds data races. It uses the same race detection algorithm as the Valgrind-based TSan, but compile-time instrumentation allows it to be much faster (2x-4x slowdown).
+ThreadSanitizer (TSan) finds data races. It uses the same race detection algorithm as the Valgrind-based TSan, but compile-time instrumentation allows it to be much faster (2x-4x slowdown).
 
 We will also share our experience in deploying theses testing tools in large software projects.
 
 
 
 Intel OpenCL SDK Vectorizer

-Nadav Rotem -  Intel
+Nadav Rotem -  Intel

 In this talk, we will present our OpenCL SDK and its core technology ??? the vectorizer compiler. We plan to present an overview of our vectorizer and discuss our experience with the LLVM compiler toolkit over the last few years. We will discuss some of our design decisions and our and plans for future features (future instruction sets, vector select, predicated instructions, etc).
 
 



From sabre at nondot.org  Sun Nov  6 00:27:38 2011
From: sabre at nondot.org (Chris Lattner)
Date: Sun, 06 Nov 2011 05:27:38 -0000
Subject: [llvm-commits] [www] r143859 - /www/trunk/index.html
Message-ID: <20111106052738.83C542A6C12C@llvm.org>

Author: lattner
Date: Sun Nov  6 00:27:38 2011
New Revision: 143859

URL: http://llvm.org/viewvc/llvm-project?rev=143859&view=rev
Log:
llvm-gcc?  what llvm-gcc.  Mention that dragonegg is useful if you want OpenMP.

Modified:
    www/trunk/index.html

Modified: www/trunk/index.html
URL: http://llvm.org/viewvc/llvm-project/www/trunk/index.html?rev=143859&r1=143858&r2=143859&view=diff
==============================================================================
--- www/trunk/index.html (original)
+++ www/trunk/index.html Sun Nov  6 00:27:38 2011
@@ -53,14 +53,11 @@
     sort of tool that can be built using the Clang frontend as a library to
     parse C/C++ code.
     
-dragonegg and
-    llvm-gcc 4.2
-    integrate the LLVM
-    optimizers and code generator with the GCC 4.5 (which is GPL3) and GCC 4.2
-    (which is GPL2) parsers, respectively.  This allows LLVM to compile Ada,
+
dragonegg 
+    integrates the LLVM optimizers and code generator with the GCC 4.5
+    parsers.  This allows LLVM to compile Ada,
     Fortran, and other languages supported by the GCC compiler frontends, and
-    provides high-fidelity drop-in compatibility with their
-    respective versions of GCC.
+    access to C features not supported by Clang (such as OpenMP).
 
 The LLDB project builds on
     libraries provided by LLVM and Clang to provide a great native debugger.



From gkistanova at gmail.com  Sun Nov  6 01:12:12 2011
From: gkistanova at gmail.com (Galina Kistanova)
Date: Sun, 06 Nov 2011 06:12:12 -0000
Subject: [llvm-commits] [zorg] r143860 -
	/zorg/trunk/buildbot/osuosl/master/templates/root.html
Message-ID: <20111106061212.85A242A6C12C@llvm.org>

Author: gkistanova
Date: Sun Nov  6 01:12:12 2011
New Revision: 143860

URL: http://llvm.org/viewvc/llvm-project?rev=143860&view=rev
Log:
Fixed few typos. Patch by Joe Abbey!

Modified:
    zorg/trunk/buildbot/osuosl/master/templates/root.html

Modified: zorg/trunk/buildbot/osuosl/master/templates/root.html
URL: http://llvm.org/viewvc/llvm-project/zorg/trunk/buildbot/osuosl/master/templates/root.html?rev=143860&r1=143859&r2=143860&view=diff
==============================================================================
--- zorg/trunk/buildbot/osuosl/master/templates/root.html (original)
+++ zorg/trunk/buildbot/osuosl/master/templates/root.html Sun Nov  6 01:12:12 2011
@@ -16,9 +16,9 @@
 !
 
 
-
Our goal is to provide a good build and test overage for all supported platforms.
+Our goal is to provide extensive build and test coverage for all supported platforms.
 
-  If you are willing to donate some CPU circles and some room on a hard drive, you are welcome.
+  If you are willing to donate some CPU cycles and some room on a hard drive, you are welcome.
   The instructions of how to add a build slave to the LLVM Buildbot infrastructure can be found
   in the
   



From craig.topper at gmail.com  Sun Nov  6 01:12:20 2011
From: craig.topper at gmail.com (Craig Topper)
Date: Sun, 06 Nov 2011 06:12:20 -0000
Subject: [llvm-commits] [llvm] r143861 - in /llvm/trunk:
 include/llvm/IntrinsicsX86.td lib/Target/X86/X86InstrFormats.td
 lib/Target/X86/X86InstrSSE.td test/CodeGen/X86/avx2-intrinsics-x86.ll
Message-ID: <20111106061221.00F5E2A6C12C@llvm.org>

Author: ctopper
Date: Sun Nov  6 01:12:20 2011
New Revision: 143861

URL: http://llvm.org/viewvc/llvm-project?rev=143861&view=rev
Log:
Add more AVX2 instructions and intrinsics.

Modified:
    llvm/trunk/include/llvm/IntrinsicsX86.td
    llvm/trunk/lib/Target/X86/X86InstrFormats.td
    llvm/trunk/lib/Target/X86/X86InstrSSE.td
    llvm/trunk/test/CodeGen/X86/avx2-intrinsics-x86.ll

Modified: llvm/trunk/include/llvm/IntrinsicsX86.td
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/IntrinsicsX86.td?rev=143861&r1=143860&r2=143861&view=diff
==============================================================================
--- llvm/trunk/include/llvm/IntrinsicsX86.td (original)
+++ llvm/trunk/include/llvm/IntrinsicsX86.td Sun Nov  6 01:12:20 2011
@@ -1668,22 +1668,52 @@
   def int_x86_avx2_pblendw : GCCBuiltin<"__builtin_ia32_pblendw256">,
               Intrinsic<[llvm_v16i16_ty], [llvm_v16i16_ty, llvm_v16i16_ty,
                          llvm_i32_ty], [IntrNoMem]>;
+  def int_x86_avx2_pblendd_128 : GCCBuiltin<"__builtin_ia32_pblendd128">,
+              Intrinsic<[llvm_v4i32_ty], [llvm_v4i32_ty, llvm_v4i32_ty,
+                         llvm_i32_ty], [IntrNoMem]>;
+  def int_x86_avx2_pblendd_256 : GCCBuiltin<"__builtin_ia32_pblendd256">,
+              Intrinsic<[llvm_v8i32_ty], [llvm_v8i32_ty, llvm_v8i32_ty,
+                         llvm_i32_ty], [IntrNoMem]>;
 }
 
 // Vector load with broadcast
 let TargetPrefix = "x86" in {  // All intrinsics start with "llvm.x86.".
   def int_x86_avx2_vbroadcast_ss_ps :
-        GCCBuiltin<"__builtin_ia32_vbroadcastss_ps">,
-        Intrinsic<[llvm_v4f32_ty], [llvm_v4f32_ty], [IntrReadMem]>;
+              GCCBuiltin<"__builtin_ia32_vbroadcastss_ps">,
+              Intrinsic<[llvm_v4f32_ty], [llvm_v4f32_ty], [IntrNoMem]>;
   def int_x86_avx2_vbroadcast_sd_pd_256 :
-        GCCBuiltin<"__builtin_ia32_vbroadcastsd_pd256">,
-        Intrinsic<[llvm_v4f64_ty], [llvm_v2f64_ty], [IntrReadMem]>;
+              GCCBuiltin<"__builtin_ia32_vbroadcastsd_pd256">,
+              Intrinsic<[llvm_v4f64_ty], [llvm_v2f64_ty], [IntrNoMem]>;
   def int_x86_avx2_vbroadcast_ss_ps_256 :
-        GCCBuiltin<"__builtin_ia32_vbroadcastss_ps256">,
-        Intrinsic<[llvm_v8f32_ty], [llvm_v4f32_ty], [IntrReadMem]>;
+              GCCBuiltin<"__builtin_ia32_vbroadcastss_ps256">,
+              Intrinsic<[llvm_v8f32_ty], [llvm_v4f32_ty], [IntrNoMem]>;
   def int_x86_avx2_vbroadcasti128 :
-        GCCBuiltin<"__builtin_ia32_vbroadcastsi256">,
-        Intrinsic<[llvm_v4i64_ty], [llvm_ptr_ty], [IntrReadMem]>;
+              GCCBuiltin<"__builtin_ia32_vbroadcastsi256">,
+              Intrinsic<[llvm_v4i64_ty], [llvm_ptr_ty], [IntrReadMem]>;
+  def int_x86_avx2_pbroadcastb_128 :
+              GCCBuiltin<"__builtin_ia32_pbroadcastb128">,
+              Intrinsic<[llvm_v16i8_ty], [llvm_v16i8_ty], [IntrNoMem]>;
+  def int_x86_avx2_pbroadcastb_256 :
+              GCCBuiltin<"__builtin_ia32_pbroadcastb256">,
+              Intrinsic<[llvm_v32i8_ty], [llvm_v16i8_ty], [IntrNoMem]>;
+  def int_x86_avx2_pbroadcastw_128 :
+              GCCBuiltin<"__builtin_ia32_pbroadcastw128">,
+              Intrinsic<[llvm_v8i16_ty], [llvm_v8i16_ty], [IntrNoMem]>;
+  def int_x86_avx2_pbroadcastw_256 :
+              GCCBuiltin<"__builtin_ia32_pbroadcastw256">,
+              Intrinsic<[llvm_v16i16_ty], [llvm_v8i16_ty], [IntrNoMem]>;
+  def int_x86_avx2_pbroadcastd_128 :
+              GCCBuiltin<"__builtin_ia32_pbroadcastd128">,
+              Intrinsic<[llvm_v4i32_ty], [llvm_v4i32_ty], [IntrNoMem]>;
+  def int_x86_avx2_pbroadcastd_256 :
+              GCCBuiltin<"__builtin_ia32_pbroadcastd256">,
+              Intrinsic<[llvm_v8i32_ty], [llvm_v4i32_ty], [IntrNoMem]>;
+  def int_x86_avx2_pbroadcastq_128 :
+              GCCBuiltin<"__builtin_ia32_pbroadcastq128">,
+              Intrinsic<[llvm_v2i64_ty], [llvm_v2i64_ty], [IntrNoMem]>;
+  def int_x86_avx2_pbroadcastq_256 :
+              GCCBuiltin<"__builtin_ia32_pbroadcastq256">,
+              Intrinsic<[llvm_v4i64_ty], [llvm_v2i64_ty], [IntrNoMem]>;
 }
 
 // Misc.

Modified: llvm/trunk/lib/Target/X86/X86InstrFormats.td
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrFormats.td?rev=143861&r1=143860&r2=143861&view=diff
==============================================================================
--- llvm/trunk/lib/Target/X86/X86InstrFormats.td (original)
+++ llvm/trunk/lib/Target/X86/X86InstrFormats.td Sun Nov  6 01:12:20 2011
@@ -451,6 +451,20 @@
       : Ii8, TA, OpSize,
         Requires<[HasAVX]>;
 
+// AVX2 Instruction Templates:
+//   Instructions introduced in AVX2 (no SSE equivalent forms)
+//
+//   AVX28I - AVX2 instructions with T8 and OpSize prefix.
+//   AVX2AIi8 - AVX2 instructions with TA, OpSize prefix and ImmT = Imm8.
+class AVX28I o, Format F, dag outs, dag ins, string asm,
+            list pattern>
+      : I, T8, OpSize,
+        Requires<[HasAVX2]>;
+class AVX2Ii8 o, Format F, dag outs, dag ins, string asm,
+              list pattern>
+      : Ii8, TA, OpSize,
+        Requires<[HasAVX2]>;
+
 // AES Instruction Templates:
 //
 // AES8I

Modified: llvm/trunk/lib/Target/X86/X86InstrSSE.td
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrSSE.td?rev=143861&r1=143860&r2=143861&view=diff
==============================================================================
--- llvm/trunk/lib/Target/X86/X86InstrSSE.td (original)
+++ llvm/trunk/lib/Target/X86/X86InstrSSE.td Sun Nov  6 01:12:20 2011
@@ -7083,11 +7083,12 @@
         !strconcat(OpcodeStr, "\t{$src, $dst|$dst, $src}"),
         [(set RC:$dst, (Int addr:$src))]>, VEX;
 
-class avx_broadcast_reg opc, string OpcodeStr, RegisterClass RC,
-                        Intrinsic Int> :
-  AVX8I, VEX;
+// AVX2 adds register forms
+class avx2_broadcast_reg opc, string OpcodeStr, RegisterClass RC,
+                         Intrinsic Int> :
+  AVX28I, VEX;
 
 def VBROADCASTSSrm  : avx_broadcast<0x18, "vbroadcastss", VR128, f32mem,
                                     int_x86_avx_vbroadcast_ss>;
@@ -7098,16 +7099,16 @@
 def VBROADCASTF128 : avx_broadcast<0x1A, "vbroadcastf128", VR256, f128mem,
                                    int_x86_avx_vbroadcastf128_pd_256>;
 
-let Predicates = [HasAVX2] in {
-def VBROADCASTI128 : avx_broadcast<0x5A, "vbroadcasti128", VR256, i128mem,
-                                   int_x86_avx2_vbroadcasti128>;
-def VBROADCASTSSrr  : avx_broadcast_reg<0x18, "vbroadcastss", VR128,
+def VBROADCASTSSrr  : avx2_broadcast_reg<0x18, "vbroadcastss", VR128,
                                         int_x86_avx2_vbroadcast_ss_ps>;
-def VBROADCASTSSYrr : avx_broadcast_reg<0x18, "vbroadcastss", VR256,
+def VBROADCASTSSYrr : avx2_broadcast_reg<0x18, "vbroadcastss", VR256,
                                         int_x86_avx2_vbroadcast_ss_ps_256>;
-def VBROADCASTSDrr  : avx_broadcast_reg<0x19, "vbroadcastsd", VR256,
+def VBROADCASTSDrr  : avx2_broadcast_reg<0x19, "vbroadcastsd", VR256,
                                         int_x86_avx2_vbroadcast_sd_pd_256>;
-}
+
+let Predicates = [HasAVX2] in
+def VBROADCASTI128 : avx_broadcast<0x5A, "vbroadcasti128", VR256, i128mem,
+                                   int_x86_avx2_vbroadcasti128>;
 
 def : Pat<(int_x86_avx_vbroadcastf128_ps_256 addr:$src),
           (VBROADCASTF128 addr:$src)>;
@@ -7364,7 +7365,7 @@
 
 //===----------------------------------------------------------------------===//
 // Half precision conversion instructions
-//
+//===----------------------------------------------------------------------===//
 multiclass f16c_ph2ps {
 let Predicates = [HasAVX, HasF16C] in {
   def rr : I<0x13, MRMSrcReg, (outs RC:$dst), (ins VR128:$src),
@@ -7396,3 +7397,71 @@
 defm VCVTPH2PSY : f16c_ph2ps;
 defm VCVTPS2PH  : f16c_ps2ph;
 defm VCVTPS2PHY : f16c_ps2ph;
+
+//===----------------------------------------------------------------------===//
+// AVX2 Instructions
+//===----------------------------------------------------------------------===//
+
+/// AVX2I_binop_rmi_int - AVX2 binary operator with 8-bit immediate
+multiclass AVX2I_binop_rmi_int opc, string OpcodeStr,
+                 Intrinsic IntId, RegisterClass RC, PatFrag memop_frag,
+                 X86MemOperand x86memop> {
+  let isCommutable = 1 in
+  def rri : AVX2Ii8,
+        VEX_4V;
+  def rmi : AVX2Ii8,
+        VEX_4V;
+}
+
+let isCommutable = 0 in {
+defm VPBLENDD : AVX2I_binop_rmi_int<0x02, "vpblendd", int_x86_avx2_pblendd_128,
+                                    VR128, memopv16i8, i128mem>;
+defm VPBLENDDY : AVX2I_binop_rmi_int<0x02, "vpblendd", int_x86_avx2_pblendd_256,
+                                     VR256, memopv32i8, i256mem>;
+}
+
+//===----------------------------------------------------------------------===//
+// VPBROADCAST - Load from memory and broadcast to all elements of the
+//               destination operand
+//
+multiclass avx2_broadcast opc, string OpcodeStr,
+                          X86MemOperand x86memop, PatFrag ld_frag,
+                          Intrinsic Int128, Intrinsic Int256> {
+  def rr : AVX28I, VEX;
+  def rm : AVX28I, VEX;
+  def Yrr : AVX28I, VEX;
+  def Yrm : AVX28I, VEX;
+}
+
+defm VPBROADCASTB  : avx2_broadcast<0x78, "vpbroadcastb", i8mem, loadi8,
+                                    int_x86_avx2_pbroadcastb_128,
+                                    int_x86_avx2_pbroadcastb_256>;
+defm VPBROADCASTW  : avx2_broadcast<0x79, "vpbroadcastw", i16mem, loadi16,
+                                    int_x86_avx2_pbroadcastw_128,
+                                    int_x86_avx2_pbroadcastw_256>;
+defm VPBROADCASTD  : avx2_broadcast<0x58, "vpbroadcastd", i32mem, loadi32,
+                                    int_x86_avx2_pbroadcastd_128,
+                                    int_x86_avx2_pbroadcastd_256>;
+defm VPBROADCASTQ  : avx2_broadcast<0x59, "vpbroadcastq", i64mem, loadi64,
+                                    int_x86_avx2_pbroadcastq_128,
+                                    int_x86_avx2_pbroadcastq_256>;

Modified: llvm/trunk/test/CodeGen/X86/avx2-intrinsics-x86.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/avx2-intrinsics-x86.ll?rev=143861&r1=143860&r2=143861&view=diff
==============================================================================
--- llvm/trunk/test/CodeGen/X86/avx2-intrinsics-x86.ll (original)
+++ llvm/trunk/test/CodeGen/X86/avx2-intrinsics-x86.ll Sun Nov  6 01:12:20 2011
@@ -766,3 +766,83 @@
   ret <8 x float> %res
 }
 declare <8 x float> @llvm.x86.avx2.vbroadcast.ss.ps.256(<4 x float>) nounwind readonly
+
+
+define <4 x i32> @test_x86_avx2_pblendd_128(<4 x i32> %a0, <4 x i32> %a1) {
+  ; CHECK: vpblendd
+  %res = call <4 x i32> @llvm.x86.avx2.pblendd.128(<4 x i32> %a0, <4 x i32> %a1, i32 7) ; <<4 x i32>> [#uses=1]
+  ret <4 x i32> %res
+}
+declare <4 x i32> @llvm.x86.avx2.pblendd.128(<4 x i32>, <4 x i32>, i32) nounwind readnone
+
+
+define <8 x i32> @test_x86_avx2_pblendd_256(<8 x i32> %a0, <8 x i32> %a1) {
+  ; CHECK: vpblendd
+  %res = call <8 x i32> @llvm.x86.avx2.pblendd.256(<8 x i32> %a0, <8 x i32> %a1, i32 7) ; <<8 x i32>> [#uses=1]
+  ret <8 x i32> %res
+}
+declare <8 x i32> @llvm.x86.avx2.pblendd.256(<8 x i32>, <8 x i32>, i32) nounwind readnone
+
+
+define <16 x i8> @test_x86_avx2_pbroadcastb_128(<16 x i8> %a0) {
+  ; CHECK: vpbroadcastb
+  %res = call <16 x i8> @llvm.x86.avx2.pbroadcastb.128(<16 x i8> %a0) ; <<16 x i8>> [#uses=1]
+  ret <16 x i8> %res
+}
+declare <16 x i8> @llvm.x86.avx2.pbroadcastb.128(<16 x i8>) nounwind readonly
+
+
+define <32 x i8> @test_x86_avx2_pbroadcastb_256(<16 x i8> %a0) {
+  ; CHECK: vpbroadcastb
+  %res = call <32 x i8> @llvm.x86.avx2.pbroadcastb.256(<16 x i8> %a0) ; <<32 x i8>> [#uses=1]
+  ret <32 x i8> %res
+}
+declare <32 x i8> @llvm.x86.avx2.pbroadcastb.256(<16 x i8>) nounwind readonly
+
+
+define <8 x i16> @test_x86_avx2_pbroadcastw_128(<8 x i16> %a0) {
+  ; CHECK: vpbroadcastw
+  %res = call <8 x i16> @llvm.x86.avx2.pbroadcastw.128(<8 x i16> %a0) ; <<8 x i16>> [#uses=1]
+  ret <8 x i16> %res
+}
+declare <8 x i16> @llvm.x86.avx2.pbroadcastw.128(<8 x i16>) nounwind readonly
+
+
+define <16 x i16> @test_x86_avx2_pbroadcastw_256(<8 x i16> %a0) {
+  ; CHECK: vpbroadcastw
+  %res = call <16 x i16> @llvm.x86.avx2.pbroadcastw.256(<8 x i16> %a0) ; <<16 x i16>> [#uses=1]
+  ret <16 x i16> %res
+}
+declare <16 x i16> @llvm.x86.avx2.pbroadcastw.256(<8 x i16>) nounwind readonly
+
+
+define <4 x i32> @test_x86_avx2_pbroadcastd_128(<4 x i32> %a0) {
+  ; CHECK: vpbroadcastd
+  %res = call <4 x i32> @llvm.x86.avx2.pbroadcastd.128(<4 x i32> %a0) ; <<4 x i32>> [#uses=1]
+  ret <4 x i32> %res
+}
+declare <4 x i32> @llvm.x86.avx2.pbroadcastd.128(<4 x i32>) nounwind readonly
+
+
+define <8 x i32> @test_x86_avx2_pbroadcastd_256(<4 x i32> %a0) {
+  ; CHECK: vpbroadcastd
+  %res = call <8 x i32> @llvm.x86.avx2.pbroadcastd.256(<4 x i32> %a0) ; <<8 x i32>> [#uses=1]
+  ret <8 x i32> %res
+}
+declare <8 x i32> @llvm.x86.avx2.pbroadcastd.256(<4 x i32>) nounwind readonly
+
+
+define <2 x i64> @test_x86_avx2_pbroadcastq_128(<2 x i64> %a0) {
+  ; CHECK: vpbroadcastq
+  %res = call <2 x i64> @llvm.x86.avx2.pbroadcastq.128(<2 x i64> %a0) ; <<2 x i64>> [#uses=1]
+  ret <2 x i64> %res
+}
+declare <2 x i64> @llvm.x86.avx2.pbroadcastq.128(<2 x i64>) nounwind readonly
+
+
+define <4 x i64> @test_x86_avx2_pbroadcastq_256(<2 x i64> %a0) {
+  ; CHECK: vpbroadcastq
+  %res = call <4 x i64> @llvm.x86.avx2.pbroadcastq.256(<2 x i64> %a0) ; <<4 x i64>> [#uses=1]
+  ret <4 x i64> %res
+}
+declare <4 x i64> @llvm.x86.avx2.pbroadcastq.256(<2 x i64>) nounwind readonly



From geek4civic at gmail.com  Sun Nov  6 01:51:59 2011
From: geek4civic at gmail.com (NAKAMURA Takumi)
Date: Sun, 06 Nov 2011 06:51:59 -0000
Subject: [llvm-commits] [llvm] r143862 - /llvm/trunk/docs/GettingStarted.html
Message-ID: <20111106065159.1D42D2A6C12C@llvm.org>

Author: chapuni
Date: Sun Nov  6 01:51:58 2011
New Revision: 143862

URL: http://llvm.org/viewvc/llvm-project?rev=143862&view=rev
Log:
docs/GettingStarted.html: [Git] Add another example for "[Gmail]/Drafts" in Traditional Chinese.

Thanks to Chen Weiren.

Modified:
    llvm/trunk/docs/GettingStarted.html

Modified: llvm/trunk/docs/GettingStarted.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/GettingStarted.html?rev=143862&r1=143861&r2=143862&view=diff
==============================================================================
--- llvm/trunk/docs/GettingStarted.html (original)
+++ llvm/trunk/docs/GettingStarted.html Sun Nov  6 01:51:58 2011
@@ -889,6 +889,8 @@
         folder = "[Gmail]/Drafts"
 ; example for Japanese, "Modified UTF-7" encoded.
         folder = "[Gmail]/&Tgtm+DBN-"
+; example for Traditional Chinese
+        folder = "[Gmail]/&g0l6Pw-"
 

Library	Forms	Description
Core Libraries
LLVMArchive	`.a`	LLVM archive reading and writing
LLVMAsmParser	`.a`	LLVM assembly parsing
LLVMBCReader	`.a`	LLVM bitcode reading
LLVMBCWriter	`.a`	LLVM bitcode writing
LLVMCore	`.a`	LLVM core intermediate representation
LLVMDebugger	`.a`	Source level debugging support
LLVMLinker	`.a`	Bitcode and archive linking interface
LLVMSupport	`.a`	General support utilities
LLVMSystem	`.a`	Operating system abstraction layer
LLVMbzip2	`.a`	BZip2 compression library
Analysis Libraries
LLVMAnalysis	`.a`	Various analysis passes.
LLVMDataStructure	`.o`	Data structure analysis passes.
LLVMipa	`.a`	Inter-procedural analysis passes.
Transformation Libraries
LLVMInstrumentation	`.a`	Instrumentation passes.
LLVMipo	`.a`	All inter-procedural optimization passes.
LLVMScalarOpts	`.a`	All scalar optimization passes.
LLVMTransformUtils	`.a`	Transformation utilities used by many passes.
Code Generation Libraries
LLVMCodeGen	`.o`	Native code generation infrastructure
LLVMSelectionDAG	`.o`	Aggressive instruction selector for directed acyclic graphs
Target Libraries
LLVMARM	`.o`	Code generation for ARM architecture
LLVMCBackend	`.o`	'C' language code generator.
LLVMPowerPC	`.o`	Code generation for PowerPC architecture
LLVMSparc	`.o`	Code generation for Sparc architecture
LLVMTarget	`.a`	Generic code generation utilities.
LLVMX86	`.o`	Code generation for Intel x86 architecture
Runtime Libraries
LLVMInterpreter	`.o`	Bitcode Interpreter
LLVMJIT	`.o`	Bitcode JIT Compiler
LLVMExecutionEngine	`.o`	Virtual machine engine

- -Execution time for CBE generated executable -	- -Execution time for the LLC generated executable -
- -Execution time for program in the JIT -

Time	Talk	Location
9:00 - 9:20	Welcome Chris Lattner, Apple Inc.	Main Hall
9:20 - 10:05	Integrating LLVM into FreeBSD Brooks Davis, The FreeBSD Project	Main Hall
Intel OpenCL SDK Vectorizer Nadav Rotem, Intel	Second Hall
10:05 - 10:50	Clang MapReduce -- Automatic C++ Refactoring at Google Scale Chandler Carruth, Google	Main Hall
	PTX Back-End: GPU Programming With LLVM Justin Holewinski, Ohio State	Second Hall
	Improving LLVM Testing David Blaikie, Microsoft	TBD
10:50 - 11:05	Break	TBD
11:05 - 11:50	Extending Clang Doug Gregor, Apple Inc.	Main Hall
11:05 - 11:50	Porting LLVM to a Next Generation DSP Taylor Simpson, QuIC	Second Hall
11:50 - 12:35	DXR: Semantic Code Browsing with Clang Joshua Cranmer, Mozilla	Main Hall
11:50 - 12:35	LLVM MC In Practice Jim Grosbach, Owen Anderson Apple Inc.	Second Hall
12:35 - 1:35	Lunch	TBD
1:35 - 2:20	Using clang in the Chromium project Nico Weber, Hans Wennborg, Google	Main Hall
	Polly - First successful optimizations - How to proceed? Tobias Grosser, ENS/INRIA	Second Hall
	MC Linkers BOF Luba Tang, Mediatek	TBD
2:20 - 3:05	Android Renderscript Stephen Hines, Google	Main Hall
	SKIR: Just-in-Time Compilation for Parallelism with LLVM Jeff Fifield, University of Colorado	Second Hall
	Improving the Clang Driver James Molloy, ARM	TBD
3:05 - 3:45	Posters	TBD
3:05 - 3:45	3:45 - 4:30	Register Allocation in LLVM 3.0 Jakob Olesen, Apple	Main Hall
Exporting 3D scenes from Maya to WebGL using clang and LLVM Jochen Wilhelmy, consultant		Second Hall
4:30 - 5:15		Super-optimizing LLVM IR Duncan Sands, DeepBlueCapital	Main Hall
	Finding races and memory errors with LLVM instrumentation Konstantin Serebryany, Google	Second Hall
	Bitcode Portability/Versioning Stephen Hines, David Sehr, Google	TBD
4:30 - 5:10	Thread Safety Annotations in Clang DeLesley Hutchins, Google	Almaden Ballroom
	Backend/Infrastructure Super BoF Jim Grosbach, Apple	Second Hall
	Community Event Planning David Kipping, Qualcomm	TBD
6:30 - 9:30	Dinner (Il Fornaio - Separate registration required)

Compact Unwind @@ -1927,6 +1929,8 @@

Aggregate Types @@ -2213,6 +2210,8 @@ + +

Accurate Garbage Collection Intrinsics @@ -7082,8 +7079,6 @@ - -

'llvm.exp.*' Intrinsic @@ -7184,6 +7179,8 @@ + +

How To Release LLVM To The Public

LuaAV

Mono

Welcome to the Buildbot +{%- if title -%} + for the + {%- if title_url -%} + {{ title }} + {%- else -%} + {{ title }} + {%- endif -%} + project +{%- endif -%} +! +

Using The LLVM Libraries

Dependency Relationships Of Libraries

Dependency Relationships Of Object Files

- Always Link LLVMCore, LLVMSupport, and LLVMSystem -

- Never link both archive and re-linked library -

Navigate:

How To Release LLVM To The Public

How To Add Your Build Configuration To LLVM Buildbot Infrastructure

How To Add Your Build Configuration To LLVM Buildbot Infrastructure

LLVMBuild Guide

Glasgow Haskell Compiler (GHC)

Nightly Test Overview:

CVS Tree Overview:

Warnings during the build:

Changes to CVS:

Changes to Warnings:

Changes in the test suite:

Compilation Measurements:

Program Execution Measurements:

Programs/External

Programs/MultiSource

Programs/SingleSource

Syntax:

SPONSORED BY: QuIC, Apple

SPONSORED BY: QuIC, Apple

SPONSORED BY: QuIC, Apple

SPONSORED BY: QuIC, Apple,Google

SPONSORED BY: QuIC, Apple,Google

SPONSORED BY: QuIC, Apple, Google

+Loop Optimization Improvements +

'`llvm.exp.*`' Intrinsic @@ -7184,6 +7179,8 @@ + +