Skip to content
  1. Aug 13, 2013
  2. Aug 12, 2013
  3. Aug 09, 2013
  4. Aug 08, 2013
  5. Aug 07, 2013
  6. Aug 06, 2013
    • Tim Northover's avatar
      Refactor isInTailCallPosition handling · a4415854
      Tim Northover authored
      This change came about primarily because of two issues in the existing code.
      Niether of:
      
      define i64 @test1(i64 %val) {
        %in = trunc i64 %val to i32
        tail call i32 @ret32(i32 returned %in)
        ret i64 %val
      }
      
      define i64 @test2(i64 %val) {
        tail call i32 @ret32(i32 returned undef)
        ret i32 42
      }
      
      should be tail calls, and the function sameNoopInput is responsible. The main
      problem is that it is completely symmetric in the "tail call" and "ret" value,
      but in reality different things are allowed on each side.
      
      For these cases:
      1. Any truncation should lead to a larger value being generated by "tail call"
         than needed by "ret".
      2. Undef should only be allowed as a source for ret, not as a result of the
         call.
      
      Along the way I noticed that a mismatch between what this function treats as a
      valid truncation and what the backends see can lead to invalid calls as well
      (see x86-32 test case).
      
      This patch refactors the code so that instead of being based primarily on
      values which it recurses into when necessary, it starts by inspecting the type
      and considers each fundamental slot that the backend will see in turn. For
      example, given a pathological function that returned {{}, {{}, i32, {}}, i32}
      we would consider each "real" i32 in turn, and ask if it passes through
      unchanged. This is much closer to what the backend sees as a result of
      ComputeValueVTs.
      
      Aside from the bug fixes, this eliminates the recursion that's going on and, I
      believe, makes the bulk of the code significantly easier to understand. The
      trade-off is the nasty iterators needed to find the real types inside a
      returned value.
      
      llvm-svn: 187787
      a4415854
    • NAKAMURA Takumi's avatar
      e359e856
    • Eric Christopher's avatar
      Recommit previous cleanup with a fix for c++98 ambiguity. · 0062f2ed
      Eric Christopher authored
      llvm-svn: 187752
      0062f2ed
    • Tom Stellard's avatar
      TargetLowering: Add getVectorIdxTy() function v2 · d42c5949
      Tom Stellard authored
      This virtual function can be implemented by targets to specify the type
      to use for the index operand of INSERT_VECTOR_ELT, EXTRACT_VECTOR_ELT,
      INSERT_SUBVECTOR, EXTRACT_SUBVECTOR.  The default implementation returns
      the result from TargetLowering::getPointerTy()
      
      The previous code was using TargetLowering::getPointerTy() for vector
      indices, because this is guaranteed to be legal on all targets.  However,
      using TargetLowering::getPointerTy() can be a problem for targets with
      pointer sizes that differ across address spaces.  On such targets,
      when vectors need to be loaded or stored to an address space other than the
      default 'zero' address space (which is the address space assumed by
      TargetLowering::getPointerTy()), having an index that
      is a different size than the pointer can lead to inefficient
      pointer calculations, (e.g. 64-bit adds for a 32-bit address space).
      
      There is no intended functionality change with this patch.
      
      llvm-svn: 187748
      d42c5949
    • Eric Christopher's avatar
      Revert "Use existing builtin hashing functions to make this routine more" · 432c99af
      Eric Christopher authored
      This reverts commit r187745.
      
      llvm-svn: 187747
      432c99af
    • Eric Christopher's avatar
      Use existing builtin hashing functions to make this routine more · d728355a
      Eric Christopher authored
      simple.
      
      llvm-svn: 187745
      d728355a
Loading