Skip to content
  1. Jul 14, 2013
  2. Jul 13, 2013
  3. Jul 12, 2013
  4. Jul 11, 2013
    • Andrew Trick's avatar
      indvars: Improve LFTR by eliminating truncation when comparing against a constant. · 3095993d
      Andrew Trick authored
      Patch by Michele Scandale!
      
      Adds a special handling of the case where, during the loop exit
      condition rewriting, the exit value is a constant of bitwidth lower
      than the type of the induction variable: instead of introducing a
      trunc operation in order to match correctly the operand types, it
      allows to convert the constant value to an equivalent constant,
      depending on the initial value of the induction variable and the trip
      count, in order have an equivalent comparison between the induction
      variable and the new constant.
      
      llvm-svn: 186107
      3095993d
    • Arnold Schwaighofer's avatar
      LoopVectorize: Vectorize all accesses in address space zero with unit stride · e97c71b8
      Arnold Schwaighofer authored
      We can vectorize them because in the case where we wrap in the address space the
      unvectorized code would have had to access a pointer value of zero which is
      undefined behavior in address space zero according to the LLVM IR semantics.
      (Thank you Duncan, for pointing this out to me).
      
      Fixes PR16592.
      
      llvm-svn: 186088
      e97c71b8
    • Duncan Sands's avatar
      TryToSimplifyUncondBranchFromEmptyBlock was checking that any common · e773c080
      Duncan Sands authored
      predecessors of the two blocks it is attempting to merge supply the
      same incoming values to any phi in the successor block.  This change
      allows merging in the case where there is one or more incoming values
      that are undef.  The undef values are rewritten to match the non-undef
      value that flows from the other edge.  Patch by Mark Lacey.
      
      llvm-svn: 186069
      e773c080
    • Nadav Rotem's avatar
      Consolidate more lit tests. · 108ef760
      Nadav Rotem authored
      llvm-svn: 186063
      108ef760
    • Nadav Rotem's avatar
      Consolidate some of the lit tests. · e0a49499
      Nadav Rotem authored
      llvm-svn: 186062
      e0a49499
    • Nadav Rotem's avatar
      Consolidate some of the lit tests. · c6b5e249
      Nadav Rotem authored
      llvm-svn: 186060
      c6b5e249
    • Michael Gottesman's avatar
      Teach TailRecursionElimination to handle certain cases of nocapture escaping allocas. · b40db26e
      Michael Gottesman authored
      Without the changes introduced into this patch, if TRE saw any allocas at all,
      TRE would not perform TRE *or* mark callsites with the tail marker.
      
      Because TRE runs after mem2reg, this inadequacy is not a death sentence. But
      given a callsite A without escaping alloca argument, A may not be able to have
      the tail marker placed on it due to a separate callsite B having a write-back
      parameter passed in via an argument with the nocapture attribute.
      
      Assume that B is the only other callsite besides A and B only has nocapture
      escaping alloca arguments (*NOTE* B may have other arguments that are not passed
      allocas). In this case not marking A with the tail marker is unnecessarily
      conservative since:
      
        1. By assumption A has no escaping alloca arguments itself so it can not
           access the caller's stack via its arguments.
      
        2. Since all of B's escaping alloca arguments are passed as parameters with
           the nocapture attribute, we know that B does not stash said escaping
           allocas in a manner that outlives B itself and thus could be accessed
           indirectly by A.
      
      With the changes introduced by this patch:
      
        1. If we see any escaping allocas passed as a capturing argument, we do
           nothing and bail early.
      
        2. If we do not see any escaping allocas passed as captured arguments but we
           do see escaping allocas passed as nocapture arguments:
      
             i. We do not perform TRE to avoid PR962 since the code generator produces
                significantly worse code for the dynamic allocas that would be created
                by the TRE algorithm.
      
             ii. If we do not return twice, mark call sites without escaping allocas
                 with the tail marker. *NOTE* This excludes functions with escaping
                 nocapture allocas.
      
        3. If we do not see any escaping allocas at all (whether captured or not):
      
             i. If we do not have usage of setjmp, mark all callsites with the tail
                marker.
      
             ii. If there are no dynamic/variable sized allocas in the function,
                 attempt to perform TRE on all callsites in the function.
      
      Based off of a patch by Nick Lewycky.
      
      rdar://14324281.
      
      llvm-svn: 186057
      b40db26e
  5. Jul 10, 2013
  6. Jul 09, 2013
  7. Jul 08, 2013
  8. Jul 07, 2013
  9. Jul 06, 2013
  10. Jul 05, 2013
Loading