Skip to content
  1. Feb 25, 2014
    • Logan Chien's avatar
      Keep the link register for uwtable. · 18583d71
      Logan Chien authored
      The function with uwtable attribute might be visited by the
      stack unwinder, thus the link register should be considered
      as clobbered after the execution of the branch and link
      instruction (i.e. the definition of the machine instruction
      can't be ignored) even when the callee function are marked
      with noreturn.
      
      llvm-svn: 202165
      18583d71
    • Richard Osborne's avatar
      [XCore] Prefer to word align functions. · 8b7466e8
      Richard Osborne authored
      The behaviour of the XCore's instruction buffer means that the performance
      of the same code sequence can differ depending on whether it starts at a 4
      byte aligned address or not. Since we don't model the instruction buffer
      in the backend we have no way of knowing for sure if it is beneficial to
      word align a specific function. However, in the absence of precise
      modelling, it is better on balance to word align functions because:
      
      * It makes a fetch-nop while executing the prologue slightly less likely.
      * If we don't word align functions then a small perturbation in one
        function can have a dramatic knock on effect. If the size of the function
        changes it might change the alignment and therefore the performance of
        all the functions that happen to follow it in the binary. This butterfly
        effect makes it harder to reason about and measure the performance of
        code.
      
      llvm-svn: 202163
      8b7466e8
    • Rafael Espindola's avatar
      Factor out calls to AA.getDataLayout(). · 6d6e87be
      Rafael Espindola authored
      llvm-svn: 202157
      6d6e87be
    • Rafael Espindola's avatar
      Make a few more DataLayout variables const. · 43b5a51e
      Rafael Espindola authored
      llvm-svn: 202155
      43b5a51e
    • Chandler Carruth's avatar
      [SROA] Use the original load name with the SROA-prefixed IRB rather than · 25adb7b0
      Chandler Carruth authored
      just "load". This helps avoid pointless de-duping with order-sensitive
      numbers as we already have unique names from the original load. It also
      makes the resulting IR quite a bit easier to read.
      
      llvm-svn: 202140
      25adb7b0
    • Chandler Carruth's avatar
      [SROA] Thread the ability to add a pointer-specific name prefix through · cb93cd2d
      Chandler Carruth authored
      the pointer adjustment code. This is the primary code path that creates
      totally new instructions in SROA and being able to lump them based on
      the pointer value's name for which they were created causes
      *significantly* fewer name collisions and general noise in the debug
      output. This is particularly significant because it is making it much
      harder to track down instability in the output of SROA, as name
      de-duplication is a totally harmless form of instability that gets in
      the way of seeing real problems.
      
      The new fancy naming scheme tries to dig out the root "pre-SROA" name
      for pointer values and associate that all the way through the pointer
      formation instructions. Digging out the root is important to prevent the
      multiple iterative rounds of SROA from just layering too much cruft on
      top of cruft here. We already track the layers of SROAs iteration in the
      alloca name prefix. We don't need to duplicate it here.
      
      Should have no functionality change, and shouldn't have any really
      measurable impact on NDEBUG builds, as most of the complex logic is
      debug-only.
      
      llvm-svn: 202139
      cb93cd2d
    • Chandler Carruth's avatar
      [SROA] Rather than copying the logic for building a name prefix into the · 51175533
      Chandler Carruth authored
      PHI-pointer builder, just copy the builder and clobber the obvious
      fields.
      
      llvm-svn: 202136
      51175533
    • Chandler Carruth's avatar
      [SROA] Simplify some of the logic to dig out the old pointer value by · 8183a50f
      Chandler Carruth authored
      using OldPtr more heavily. Lots of this code was written before the
      rewriter had an OldPtr member setup ahead of time. There are already
      asserts in place that should ensure this doesn't change any
      functionality.
      
      llvm-svn: 202135
      8183a50f
    • Chandler Carruth's avatar
      [SROA] Adjust to new clang-format style. · 7625c54e
      Chandler Carruth authored
      llvm-svn: 202134
      7625c54e
    • Nico Rieck's avatar
      Reuse constants for COFF string table entry offsets · 01143f9a
      Nico Rieck authored
      llvm-svn: 202130
      01143f9a
    • Chandler Carruth's avatar
      [SROA] Fix a *glaring* bug in r202091: you have to actually *write* · a8c4cc68
      Chandler Carruth authored
      the break statement, not just think it to yourself....
      
      No idea how this worked at all, much less survived most bots, my
      bootstrap, and some bot bootstraps!
      
      The Polly one didn't survive, and this was filed as PR18959. I don't
      have a reduced test case and honestly I'm not seeing the need. What we
      probably need here are better asserts / debug-build behavior in
      SmallPtrSet so that this madness doesn't make it so far.
      
      llvm-svn: 202129
      a8c4cc68
    • Renato Golin's avatar
      Disable old JIT unittests for AARch64 · dd8c8018
      Renato Golin authored
      llvm-svn: 202127
      dd8c8018
    • Renato Golin's avatar
      Ignore old JIT tests in AARch64 - CMake style · 69736692
      Renato Golin authored
      llvm-svn: 202126
      69736692
    • Renato Golin's avatar
      Add aarch64 to config.guess · 882e947d
      Renato Golin authored
      llvm-svn: 202125
      882e947d
    • Alexey Samsonov's avatar
      Silence GCC warning · 26af6f7f
      Alexey Samsonov authored
      llvm-svn: 202119
      26af6f7f
    • Alp Toker's avatar
      Fix typos · 70b36995
      Alp Toker authored
      llvm-svn: 202107
      70b36995
    • Chandler Carruth's avatar
      [SROA] Add a debugging tool which shuffles the slices sequence prior to · 83cee772
      Chandler Carruth authored
      sorting it. This helps uncover latent reliance on the original ordering
      which aren't guaranteed to be preserved by std::sort (but often are),
      and which are based on the use-def chain orderings which also aren't
      (technically) guaranteed.
      
      Only available in C++11 debug builds, and behind a flag to prevent noise
      at the moment, but this is generally useful so figured I'd put it in the
      tree rather than keeping it out-of-tree.
      
      llvm-svn: 202106
      83cee772
    • Chandler Carruth's avatar
      [SROA] Use a more direct way of determining whether we are processing · bb2a9324
      Chandler Carruth authored
      the destination operand or source operand of a memmove.
      
      It so happens that it was impossible for SROA to try to rewrite
      self-memmove where the operands are *identical*, because either such
      a think is volatile (and we don't rewrite) or it is non-volatile, and we
      don't even register it as a use of the alloca.
      
      However, making the 'IsDest' test *rely* on this subtle fact is... Very
      confusing for the reader. We should use the direct and readily available
      test of the Use* which gives us concrete information about which operand
      is being rewritten.
      
      No functionality changed, I hope! ;]
      
      llvm-svn: 202103
      bb2a9324
    • Chandler Carruth's avatar
      Add some convenience accessors for the underlying Use of an operand. · fbe7dc33
      Chandler Carruth authored
      These complement many of the existing accessors and make it
      significantly easier to write code which needs to poke at the underlying
      Use without hard coding the operand number at which it resides for
      a particular instruction. No functionality changed of course.
      
      llvm-svn: 202102
      fbe7dc33
    • Nick Lewycky's avatar
      Indent this continued line. · 1ce017e8
      Nick Lewycky authored
      llvm-svn: 202096
      1ce017e8
    • Chandler Carruth's avatar
      [SROA] Fix another instability in SROA with respect to the slice · 3bf18ed5
      Chandler Carruth authored
      ordering.
      
      The fundamental problem that we're hitting here is that the use-def
      chain ordering is *itself* not a stable thing to be relying on in the
      rewriting for SROA. Further, we use a non-stable sort over the slices to
      arrange them based on the section of the alloca they're operating on.
      With a debugging STL implementation (or different implementations in
      stage2 and stage3) this can cause stage2 != stage3.
      
      The specific aspect of this problem fixed in this commit deals with the
      rewriting and load-speculation around PHIs and Selects. This, like many
      other aspects of the use-rewriting in SROA, is really part of the
      "strong SSA-formation" that is doen by SROA where it works very hard to
      canonicalize loads and stores in *just* the right way to satisfy the
      needs of mem2reg[1]. When we have a select (or a PHI) with 2 uses of the
      same alloca, we test that loads downstream of the select are
      speculatable around it twice. If only one of the operands to the select
      needs to be rewritten, then if we get lucky we rewrite that one first
      and the select is immediately speculatable. This can cause the order of
      operand visitation, and thus the order of slices to be rewritten, to
      change an alloca from promotable to non-promotable and vice versa.
      
      The fix is to defer all of the speculation until *after* the rewrite
      phase is done. Once we've rewritten everything, we can accurately test
      for whether speculation will work (once, instead of twice!) and the
      order ceases to matter.
      
      This also happens to simplify the other subtlety of speculation -- we
      need to *not* speculate anything unless the result of speculating will
      make the alloca fully promotable by mem2reg. I had a previous attempt at
      simplifying this, but it was still pretty horrible.
      
      There is actually already a *really* nice test case for this in
      basictest.ll, but on multiple STL implementations and inputs, we just
      got "lucky". Fortunately, the test case is very small and we can
      essentially build it in exactly the opposite way to get reasonable
      coverage in both directions even from normal STL implementations.
      
      llvm-svn: 202092
      3bf18ed5
    • David Blaikie's avatar
    • Rafael Espindola's avatar
      Make some DataLayout pointers const. · aeff8a9c
      Rafael Espindola authored
      No functionality change. Just reduces the noise of an upcoming patch.
      
      llvm-svn: 202087
      aeff8a9c
  2. Feb 24, 2014
Loading