Skip to content
  1. Jun 26, 2012
    • Argyrios Kyrtzidis's avatar
      Fix ThreadLocalImpl::getInstance for --disable-threads. · 46785f94
      Argyrios Kyrtzidis authored
      PR13114.
      
      llvm-svn: 159210
      46785f94
    • Jakob Stoklund Olesen's avatar
      Allow targets to inject passes before the virtual register rewriter. · 59a0d324
      Jakob Stoklund Olesen authored
      Such passes can be used to tweak the register assignments in a
      target-dependent way, for example to avoid write-after-write
      dependencies.
      
      llvm-svn: 159209
      59a0d324
    • Jack Carter's avatar
      There are a number of generic inline asm operand modifiers that · 5e69cffe
      Jack Carter authored
      up to r158925 were handled as processor specific. Making them 
      generic and putting tests for these modifiers in the CodeGen/Generic
      directory caused a number of targets to fail. 
      
      This commit addresses that problem by having the targets call 
      the generic routine for generic modifiers that they don't currently
      have explicit code for.
      
      For now only generic print operands 'c' and 'n' are supported.vi
      
      
      Affected files:
      
          test/CodeGen/Generic/asm-large-immediate.ll
          lib/Target/PowerPC/PPCAsmPrinter.cpp
          lib/Target/NVPTX/NVPTXAsmPrinter.cpp
          lib/Target/ARM/ARMAsmPrinter.cpp
          lib/Target/XCore/XCoreAsmPrinter.cpp
          lib/Target/X86/X86AsmPrinter.cpp
          lib/Target/Hexagon/HexagonAsmPrinter.cpp
          lib/Target/CellSPU/SPUAsmPrinter.cpp
          lib/Target/Sparc/SparcAsmPrinter.cpp
          lib/Target/MBlaze/MBlazeAsmPrinter.cpp
          lib/Target/Mips/MipsAsmPrinter.cpp
          
      MSP430 isn't represented because it did not even run with
      the long existing 'c' modifier and it was not apparent what
      needs to be done to get it inline asm ready.
      
      Contributer: Jack Carter
      llvm-svn: 159203
      5e69cffe
    • Duncan Sands's avatar
      Replacing zero-sized alloca's with a null pointer is too aggressive, instead · 8bc764ae
      Duncan Sands authored
      merge all zero-sized alloca's into one, fixing c43204g from the Ada ACATS
      conformance testsuite.  What happened there was that a variable sized object
      was being allocated on the stack, "alloca i8, i32 %size".  It was then being
      passed to another function, which tested that the address was not null (raising
      an exception if it was) then manipulated %size bytes in it (load and/or store).
      The optimizers cleverly managed to deduce that %size was zero (congratulations
      to them, as it isn't at all obvious), which made the alloca zero size, causing
      the optimizers to replace it with null, which then caused the check mentioned
      above to fail, and the exception to be raised, wrongly.  Note that no loads
      and stores were actually being done to the alloca (the loop that does them is
      executed %size times, i.e. is not executed), only the not-null address check.
      
      llvm-svn: 159202
      8bc764ae
    • Elena Demikhovsky's avatar
      Removed unused variable · 863d2d32
      Elena Demikhovsky authored
      llvm-svn: 159197
      863d2d32
    • Bill Wendling's avatar
      Rename to match other X86_64* names. · 8ed44466
      Bill Wendling authored
      llvm-svn: 159196
      8ed44466
    • Elena Demikhovsky's avatar
      Shuffle optimization for AVX/AVX2. · 26088d2e
      Elena Demikhovsky authored
      The current patch optimizes frequently used shuffle patterns and gives these instruction sequence reduction.
      Before:
            vshufps $-35, %xmm1, %xmm0, %xmm2 ## xmm2 = xmm0[1,3],xmm1[1,3]
             vpermilps       $-40, %xmm2, %xmm2 ## xmm2 = xmm2[0,2,1,3]
             vextractf128    $1, %ymm1, %xmm1
             vextractf128    $1, %ymm0, %xmm0
             vshufps $-35, %xmm1, %xmm0, %xmm0 ## xmm0 = xmm0[1,3],xmm1[1,3]
             vpermilps       $-40, %xmm0, %xmm0 ## xmm0 = xmm0[0,2,1,3]
             vinsertf128     $1, %xmm0, %ymm2, %ymm0
      After:
            vshufps $13, %ymm0, %ymm1, %ymm1 ## ymm1 = ymm1[1,3],ymm0[0,0],ymm1[5,7],ymm0[4,4]
            vshufps $13, %ymm0, %ymm0, %ymm0 ## ymm0 = ymm0[1,3,0,0,5,7,4,4]
            vunpcklps       %ymm1, %ymm0, %ymm0 ## ymm0 = ymm0[0],ymm1[0],ymm0[1],ymm1[1],ymm0[4],ymm1[4],ymm0[5],ymm1[5]
      
      llvm-svn: 159188
      26088d2e
    • Chandler Carruth's avatar
      Update a bunch of stale comments that dated from when this folled the · 9139f44d
      Chandler Carruth authored
      very first (and worst) placement algorithm. These should now more
      accurately reflect the reality of the pass.
      
      llvm-svn: 159185
      9139f44d
    • Craig Topper's avatar
      Remove some duplicate instructions that exist only to given different... · 94bf0f38
      Craig Topper authored
      Remove some duplicate instructions that exist only to given different mnemonics for the assembler. Use InstAlias instead.
      
      llvm-svn: 159184
      94bf0f38
    • Andrew Trick's avatar
      Enable the new LoopInfo algorithm by default. · fb2ba3e1
      Andrew Trick authored
      The primary advantage is that loop optimizations will be applied in a
      stable order. This helps debugging and unit test creation. It is also
      a better overall implementation without pathologically bad performance
      on deep functions.
      
      On large functions (llvm-stress --size=200000 | opt -loops)
      Before: 0.1263s
      After:  0.0225s
      
      On deep functions (after tweaking llvm-stress, thanks Nadav):
      Before: 0.2281s
      After:  0.0227s
      
      See r158790 for more comments.
      
      The loop tree is now consistently generated in forward order, but loop
      passes are applied in reverse order over the program. If we have a
      loop optimization that prefers forward order, that can easily be
      achieved by adding a different type of LoopPassManager.
      
      llvm-svn: 159183
      fb2ba3e1
    • Andrew Trick's avatar
      Remove unnecessary FIXME · fecf9379
      Andrew Trick authored
      llvm-svn: 159182
      fecf9379
    • Evan Cheng's avatar
      Make sure type is not extended or untyped before create a constant of the... · 4c6f917d
      Evan Cheng authored
      Make sure type is not extended or untyped before create a constant of the type. No test case. Found by inspection.
      
      llvm-svn: 159179
      4c6f917d
    • Eli Friedman's avatar
      Make some ugly hacks for inline asm operands which name a specific register a... · bbcd09cc
      Eli Friedman authored
      Make some ugly hacks for inline asm operands which name a specific register a bit more thorough.  PR13196.
      
      llvm-svn: 159176
      bbcd09cc
    • Nuno Lopes's avatar
      revert my previous commit (r159173), since as Eli pointed out, it's perfectly... · 31b54a53
      Nuno Lopes authored
      revert my previous commit (r159173), since as Eli pointed out, it's perfectly ok to mark realloc as noalias
      
      llvm-svn: 159175
      31b54a53
    • Nuno Lopes's avatar
      do not set realloc() as NotAlias, since it can return the same pointer. This... · 75eaa72d
      Nuno Lopes authored
      do not set realloc() as NotAlias, since it can return the same pointer. This whole thing should be upgraded to use the MemoryBuiltin interface anyway..
      
      llvm-svn: 159173
      75eaa72d
  2. Jun 25, 2012
  3. Jun 24, 2012
Loading