Skip to content
  1. Mar 26, 2013
  2. Mar 01, 2013
    • Michael Liao's avatar
      Fix PR10475 · 6af16fc3
      Michael Liao authored
      - ISD::SHL/SRL/SRA must have either both scalar or both vector operands
        but TLI.getShiftAmountTy() so far only return scalar type. As a
        result, backend logic assuming that breaks.
      - Rename the original TLI.getShiftAmountTy() to
        TLI.getScalarShiftAmountTy() and re-define TLI.getShiftAmountTy() to
        return target-specificed scalar type or the same vector type as the
        1st operand.
      - Fix most TICG logic assuming TLI.getShiftAmountTy() a simple scalar
        type.
      
      llvm-svn: 176364
      6af16fc3
  3. Feb 15, 2013
  4. Jan 29, 2013
    • Evan Cheng's avatar
      Teach SDISel to combine fsin / fcos into a fsincos node if the following · 0e88c7d8
      Evan Cheng authored
      conditions are met:
      1. They share the same operand and are in the same BB.
      2. Both outputs are used.
      3. The target has a native instruction that maps to ISD::FSINCOS node or
         the target provides a sincos library call.
      
      Implemented the generic optimization in sdisel and enabled it for
      Mac OSX. Also added an additional optimization for x86_64 Mac OSX by
      using an alternative entry point __sincos_stret which returns the two
      results in xmm0 / xmm1.
      
      rdar://13087969
      PR13204
      
      llvm-svn: 173755
      0e88c7d8
  5. Jan 28, 2013
  6. Jan 21, 2013
  7. Jan 20, 2013
  8. Jan 09, 2013
  9. Jan 07, 2013
    • Chandler Carruth's avatar
      Switch TargetTransformInfo from an immutable analysis pass that requires · 664e354d
      Chandler Carruth authored
      a TargetMachine to construct (and thus isn't always available), to an
      analysis group that supports layered implementations much like
      AliasAnalysis does. This is a pretty massive change, with a few parts
      that I was unable to easily separate (sorry), so I'll walk through it.
      
      The first step of this conversion was to make TargetTransformInfo an
      analysis group, and to sink the nonce implementations in
      ScalarTargetTransformInfo and VectorTargetTranformInfo into
      a NoTargetTransformInfo pass. This allows other passes to add a hard
      requirement on TTI, and assume they will always get at least on
      implementation.
      
      The TargetTransformInfo analysis group leverages the delegation chaining
      trick that AliasAnalysis uses, where the base class for the analysis
      group delegates to the previous analysis *pass*, allowing all but tho
      NoFoo analysis passes to only implement the parts of the interfaces they
      support. It also introduces a new trick where each pass in the group
      retains a pointer to the top-most pass that has been initialized. This
      allows passes to implement one API in terms of another API and benefit
      when some other pass above them in the stack has more precise results
      for the second API.
      
      The second step of this conversion is to create a pass that implements
      the TargetTransformInfo analysis using the target-independent
      abstractions in the code generator. This replaces the
      ScalarTargetTransformImpl and VectorTargetTransformImpl classes in
      lib/Target with a single pass in lib/CodeGen called
      BasicTargetTransformInfo. This class actually provides most of the TTI
      functionality, basing it upon the TargetLowering abstraction and other
      information in the target independent code generator.
      
      The third step of the conversion adds support to all TargetMachines to
      register custom analysis passes. This allows building those passes with
      access to TargetLowering or other target-specific classes, and it also
      allows each target to customize the set of analysis passes desired in
      the pass manager. The baseline LLVMTargetMachine implements this
      interface to add the BasicTTI pass to the pass manager, and all of the
      tools that want to support target-aware TTI passes call this routine on
      whatever target machine they end up with to add the appropriate passes.
      
      The fourth step of the conversion created target-specific TTI analysis
      passes for the X86 and ARM backends. These passes contain the custom
      logic that was previously in their extensions of the
      ScalarTargetTransformInfo and VectorTargetTransformInfo interfaces.
      I separated them into their own file, as now all of the interface bits
      are private and they just expose a function to create the pass itself.
      Then I extended these target machines to set up a custom set of analysis
      passes, first adding BasicTTI as a fallback, and then adding their
      customized TTI implementations.
      
      The fourth step required logic that was shared between the target
      independent layer and the specific targets to move to a different
      interface, as they no longer derive from each other. As a consequence,
      a helper functions were added to TargetLowering representing the common
      logic needed both in the target implementation and the codegen
      implementation of the TTI pass. While technically this is the only
      change that could have been committed separately, it would have been
      a nightmare to extract.
      
      The final step of the conversion was just to delete all the old
      boilerplate. This got rid of the ScalarTargetTransformInfo and
      VectorTargetTransformInfo classes, all of the support in all of the
      targets for producing instances of them, and all of the support in the
      tools for manually constructing a pass based around them.
      
      Now that TTI is a relatively normal analysis group, two things become
      straightforward. First, we can sink it into lib/Analysis which is a more
      natural layer for it to live. Second, clients of this interface can
      depend on it *always* being available which will simplify their code and
      behavior. These (and other) simplifications will follow in subsequent
      commits, this one is clearly big enough.
      
      Finally, I'm very aware that much of the comments and documentation
      needs to be updated. As soon as I had this working, and plausibly well
      commented, I wanted to get it committed and in front of the build bots.
      I'll be doing a few passes over documentation later if it sticks.
      
      Commits to update DragonEgg and Clang will be made presently.
      
      llvm-svn: 171681
      664e354d
  10. Jan 04, 2013
    • Nadav Rotem's avatar
      LoopVectorizer: · e1d5c4b8
      Nadav Rotem authored
      1. Add code to estimate register pressure.
      2. Add code to select the unroll factor based on register pressure.
      3. Add bits to TargetTransformInfo to provide the number of registers.
      
      llvm-svn: 171469
      e1d5c4b8
  11. Jan 03, 2013
  12. Dec 28, 2012
  13. Dec 27, 2012
  14. Dec 21, 2012
  15. Dec 19, 2012
  16. Dec 17, 2012
  17. Dec 15, 2012
  18. Dec 12, 2012
  19. Dec 11, 2012
  20. Dec 09, 2012
  21. Dec 08, 2012
    • Chandler Carruth's avatar
      Revert the patches adding a popcount loop idiom recognition pass. · 91e47532
      Chandler Carruth authored
      There are still bugs in this pass, as well as other issues that are
      being worked on, but the bugs are crashers that occur pretty easily in
      the wild. Test cases have been sent to the original commit's review
      thread.
      
      This reverts the commits:
        r169671: Fix a logic error.
        r169604: Move the popcnt tests to an X86 subdirectory.
        r168931: Initial commit adding the pass.
      
      llvm-svn: 169683
      91e47532
  22. Dec 06, 2012
    • Evan Cheng's avatar
      Replace r169459 with something safer. Rather than having computeMaskedBits to · 9ec512d7
      Evan Cheng authored
      understand target implementation of any_extend / extload, just generate
      zero_extend in place of any_extend for liveouts when the target knows the
      zero_extend will be implicit (e.g. ARM ldrb / ldrh) or folded (e.g. x86 movz).
      
      rdar://12771555
      
      llvm-svn: 169536
      9ec512d7
    • Evan Cheng's avatar
      Let targets provide hooks that compute known zero and ones for any_extend · 5213139f
      Evan Cheng authored
      and extload's. If they are implemented as zero-extend, or implicitly
      zero-extend, then this can enable more demanded bits optimizations. e.g.
      
      define void @foo(i16* %ptr, i32 %a) nounwind {
      entry:
        %tmp1 = icmp ult i32 %a, 100
        br i1 %tmp1, label %bb1, label %bb2
      bb1:
        %tmp2 = load i16* %ptr, align 2
        br label %bb2
      bb2:
        %tmp3 = phi i16 [ 0, %entry ], [ %tmp2, %bb1 ]
        %cmp = icmp ult i16 %tmp3, 24
        br i1 %cmp, label %bb3, label %exit
      bb3:
        call void @bar() nounwind
        br label %exit
      exit:
        ret void
      }
      
      This compiles to the followings before:
              push    {lr}
              mov     r2, #0
              cmp     r1, #99
              bhi     LBB0_2
      @ BB#1:                                 @ %bb1
              ldrh    r2, [r0]
      LBB0_2:                                 @ %bb2
              uxth    r0, r2
              cmp     r0, #23
              bhi     LBB0_4
      @ BB#3:                                 @ %bb3
              bl      _bar
      LBB0_4:                                 @ %exit
              pop     {lr}
              bx      lr
      
      The uxth is not needed since ldrh implicitly zero-extend the high bits. With
      this change it's eliminated.
      
      rdar://12771555
      
      llvm-svn: 169459
      5213139f
  23. Dec 05, 2012
  24. Dec 04, 2012
  25. Nov 29, 2012
    • Shuxin Yang's avatar
      rdar://12100355 (part 1) · abcc3704
      Shuxin Yang authored
      This revision attempts to recognize following population-count pattern:
      
       while(a) { c++; ... ; a &= a - 1; ... },
        where <c> and <a>could be used multiple times in the loop body.
      
       TODO: On X8664 and ARM, __buildin_ctpop() are not expanded to a efficent 
      instruction sequence, which need to be improved in the following commits.
      
      Reviewed by Nadav, really appreciate!
      
      llvm-svn: 168931
      abcc3704
  26. Nov 11, 2012
  27. Nov 10, 2012
Loading