Skip to content
  1. Mar 05, 2020
    • Craig Topper's avatar
      [X86] Simplify the code at the end of lowerShuffleAsBroadcast. · 4c7c87f2
      Craig Topper authored
      The original code could create a bitcast from f64 to i64 and back
      on 32-bit targets. This was only working because getBitcast was
      able to fold the casts away to avoid leaving the illegal i64 type.
      
      Now we handle the scalar case directly by broadcasting using the
      scalar type as the element type. Then bitcasting to the final VT.
      This works since we ensure the scalar type is the same size as
      the final VT element type. No more casts to i64.
      
      For the vector case, we cast to VT or subvector of VT. And then
      do the broadcast.
      
      I think this all matches what we generated before, just in a more
      readable way.
      4c7c87f2
    • Matt Arsenault's avatar
      clang: Treat ieee mode as the default for denormal-fp-math · c64ca930
      Matt Arsenault authored
      The IR hasn't switched the default yet, so explicitly add the ieee
      attributes.
      
      I'm still not really sure how the target default denormal mode should
      interact with -fno-unsafe-math-optimizations. The target may have
      selected the default mode to be non-IEEE based on the flags or based
      on its true behavior, but we don't know which is the case. Since the
      only users of a non-IEEE mode without a flag still support IEEE mode,
      just reset to IEEE.
      c64ca930
    • Philip Reames's avatar
      Consistently capitalize a variable [NFC] · c94a4133
      Philip Reames authored
      One instance in a copy paste was pointed out in a review, fix all instances at once.
      c94a4133
    • Michael Trent's avatar
      Fix dyld opcode *_ADD_ADDR_IMM_SCALED error detection. · df058699
      Michael Trent authored
      Summary:
      Move the check for malformed REBASE_OPCODE_ADD_ADDR_IMM_SCALED and
      BIND_OPCODE_DO_BIND_ADD_ADDR_IMM_SCALED opcodes after the immediate
      has been applied to the SegmentOffset. This fixes specious errors
      where SegmentOffset is pointing between two sections when trying to
      correct the SegmentOffset value.
      
      Update the regression tests to verify the proper error message.
      
      Reviewers: pete, ab, lhames, steven_wu, jhenderson
      
      Reviewed By: pete
      
      Subscribers: hiraditya, dexonsmith, rupprecht, llvm-commits
      
      Tags: #llvm
      
      Differential Revision: https://reviews.llvm.org/D75629
      df058699
    • Igor Kudrin's avatar
      [DebugInfo] Avoid crashing on an invalid section identifier. · cc61283b
      Igor Kudrin authored
      A DWARFSectionKind is read from input. It is not validated on parsing,
      so an unexpected value may result in reaching llvm_unreachable() in
      DWARFUnitIndex::getColumnHeader() when dumping the index section.
      
      Differential Revision: https://reviews.llvm.org/D75609
      cc61283b
    • QingShan Zhang's avatar
      [DAGCombine] Check the uses of negated floating constant and remove the hack · 3906ae38
      QingShan Zhang authored
      PowerPC hits an assertion due to somewhat the same reason as https://reviews.llvm.org/D70975.
      Though there are already some hack, it still failed with some case, when the operand 0 is NOT
      a const fp, it is another fma that with const fp. And that const fp is negated which result in multi-uses.
      
      A better fix is to check the uses of the negated const fp. If there are already use of its negated
      value, we will have benefit as no extra Node is added.
      
      Differential revision: https://reviews.llvm.org/D75501
      3906ae38
    • Jim Lin's avatar
      [AVR][NFC] Use Register instead of unsigned · ea6eb813
      Jim Lin authored
      Summary: Use Register type for variables instead of unsigned type.
      
      Reviewers: dylanmckay
      
      Reviewed By: dylanmckay
      
      Subscribers: hiraditya, llvm-commits
      
      Tags: #llvm
      
      Differential Revision: https://reviews.llvm.org/D75595
      ea6eb813
    • Greg Clayton's avatar
    • Greg Clayton's avatar
      Fix GSYM tests to run the yaml files and fix test failures on some machines. · 4050b01b
      Greg Clayton authored
      YAML files were not being run during lit testing as there was no lit.local.cfg file. Once this was fixed, some buildbots would fail due to a StringRef that pointed to a std::string inside of a temporary llvm::Triple object. These issues are fixed here by making a local triple object that stays around long enough so the StringRef points to valid data. Fixed memory sanitizer bot bugs as well.
      
      Differential Revision: https://reviews.llvm.org/D75390
      4050b01b
    • hsmahesha's avatar
      AMDGPU/GlobalISel: Support llvm.trap and llvm.debugtrap intrinsics · 3fda1fde
      hsmahesha authored
      Summary: Lower trap and debugtrap intrinsics to AMDGPU machine instruction(s).
      
      Reviewers: arsenm, nhaehnle, kerbowa, cdevadas, t-tye, kzhuravl
      
      Reviewed By: arsenm
      
      Subscribers: kzhuravl, jvesely, wdng, yaxunl, rovka, dstuttard, tpr, hiraditya, llvm-commits
      
      Tags: #llvm
      
      Differential Revision: https://reviews.llvm.org/D74688
      3fda1fde
    • Shengchen Kan's avatar
      [X86] Add a private member function determinePaddingPrefix for X86AsmBackend · b3722dea
      Shengchen Kan authored
      Summary: X86 can reduce the bytes of NOP by padding instructions with prefixes to get a better peformance in some cases. So a private member function `determinePaddingPrefix` is added to determine which prefix is the most suitable.
      
      Reviewers: annita.zhang, reames, MaskRay, craig.topper, LuoYuanke, jyknight
      
      Reviewed By: reames
      
      Subscribers: llvm-commits, dexonsmith, hiraditya
      
      Tags: #llvm
      
      Differential Revision: https://reviews.llvm.org/D75357
      b3722dea
    • MaheshRavishankar's avatar
      [mlir][Linalg] Fix load/store operations generated while lower loops when · 755c0502
      MaheshRavishankar authored
      output has zero rank.
      
      While lowering to loops, no indices should be used in the load/store
      operation if the buffer is zero-rank.
      
      Differential Revision: https://reviews.llvm.org/D75391
      755c0502
    • Philip Reames's avatar
      [X86] Relax existing instructions to reduce the number of nops needed for alignment purposes · f708c823
      Philip Reames authored
      If we have an explicit align directive, we currently default to emitting nops to fill the space. As discussed in the context of the prefix padding work for branch alignment (D72225), we're allowed to play other tricks such as extending the size of previous instructions instead.
      
      This patch will convert near jumps to far jumps if doing so decreases the number of bytes of nops needed for a following align. It does so as a post-pass after relaxation is complete. It intentionally works without moving any labels or doing anything which might require another round of relaxation.
      
      The point of this patch is mainly to mock out the approach. The optimization implemented is real, and possibly useful, but the main point is to demonstrate an approach for implementing such "pad previous instruction" approaches. The key notion in this patch is to treat padding previous instructions as an optional optimization, not as a core part of relaxation. The benefit to this is that we avoid the potential concern about increasing the distance between two labels and thus causing further potentially non-local code grown due to relaxation. The downside is that we may miss some opportunities to avoid nops.
      
      For the moment, this patch only implements a small set of existing relaxations.. Assuming the approach is satisfactory, I plan to extend this to a broader set of instructions where there are obvious "relaxations" which are roughly performance equivalent.
      
      Note that this patch *doesn't* change which instructions are relaxable. We may wish to explore that separately to increase optimization opportunity, but I figured that deserved it's own separate discussion.
      
      There are possible downsides to this optimization (and all "pad previous instruction" variants). The major two are potentially increasing instruction fetch and perturbing uop caching. (i.e. the usual alignment risks) Specifically:
       * If we pad an instruction such that it crosses a fetch window (16 bytes on modern X86-64), we may cause the decoder to have to trigger a fetch it wouldn't have otherwise. This can effect both decode speed, and icache pressure.
       * Intel's uop caching have particular restrictions on instruction combinations which can fit in a particular way. By moving around instructions, we can both cause misses an change misses into hits. Many of the most painful cases are around branch density, so I don't expect this to be too bad on the whole.
      
      On the whole, I expect to see small swings (i.e. the typical alignment change problem), but nothing major or systematic in either direction.
      
      Differential Revision: https://reviews.llvm.org/D75203
      f708c823
    • Louis Dionne's avatar
    • Sam McCall's avatar
      [clangd] Track document versions, include them with diags, enhance logs · 2cd33e6f
      Sam McCall authored
      Summary:
      This ties to an LSP feature (diagnostic versioning) but really a lot
      of the value is in being able to log what's happening with file versions
      and queues more descriptively and clearly.
      
      As such it's fairly invasive, for a logging patch :-\
      
      Key decisions:
       - at the LSP layer, we don't reqire the client to provide versions (LSP
         makes it mandatory but we never enforced it). If not provided,
         versions start at 0 and increment. DraftStore handles this.
       - don't propagate magically using contexts, but rather manually:
         addDocument -> ParseInputs -> (ParsedAST, Preamble, various callbacks)
         Context-propagation would hide the versions from ClangdServer, which
         would make producing good log messages hard
       - within ClangdServer, treat versions as opaque and unordered.
         std::string is a convenient type for this, and allows richer versions
         for embedders. They're "mandatory" but "null" is a reasonable default.
      
      Subscribers: ilya-biryukov, javed.absar, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits
      
      Tags: #clang
      
      Differential Revision: https://reviews.llvm.org/D75582
      2cd33e6f
    • Sam McCall's avatar
      e6d9b2cb
    • Petr Hosek's avatar
      Revert "[clang-doc] Improving Markdown Output" · ea086d10
      Petr Hosek authored
      This reverts commit 45499f38, it's
      still failing on Windows bots.
      ea086d10
    • Matt Arsenault's avatar
      Add constexpr to DenormalMode constructors · b2dcde08
      Matt Arsenault authored
      This will allow their use in member initializers in a future commit.
      b2dcde08
    • Matt Arsenault's avatar
      X86: Generate mir checks in sqrt test · 7459781b
      Matt Arsenault authored
      7459781b
    • Stefan Gränitz's avatar
      [ORC] Decompose LazyCallThroughManager::callThroughToSymbol() · 76c59a63
      Stefan Gränitz authored
      Summary: Decompose callThroughToSymbol() into findReexport(), resolveSymbol(), notifyResolved() and reportCallThroughError(). This allows derived classes to reuse the functionality while adding their own code in between.
      
      Reviewers: lhames
      
      Reviewed By: lhames
      
      Subscribers: hiraditya, steven_wu, dexonsmith, llvm-commits
      
      Tags: #llvm
      
      Differential Revision: https://reviews.llvm.org/D75084
      76c59a63
    • Sam McCall's avatar
      [clangd] Cancel certain operations if the file changes before we start. · c627b120
      Sam McCall authored
      Summary:
      Otherwise they can force us to build lots of snapshots that we don't need.
      Particularly, try to do this for operations that are frequently
      generated by editors without explicit user interaction, and where
      editing the file makes the result less useful. (Code action
      enumeration is a good example).
      
      https://github.com/clangd/clangd/issues/298
      
      This doesn't return the "right" LSP error code (ContentModified) to the client,
      we need to teach the cancellation API to distinguish between different causes.
      
      Reviewers: kadircet
      
      Subscribers: ilya-biryukov, javed.absar, MaskRay, jkorous, arphaman, jfb, usaxena95, cfe-commits
      
      Tags: #clang
      
      Differential Revision: https://reviews.llvm.org/D75602
      c627b120
    • Craig Topper's avatar
      [X86] Convert vXi1 vectors to xmm/ymm/zmm types via... · eadea786
      Craig Topper authored
      [X86] Convert vXi1 vectors to xmm/ymm/zmm types via getRegisterTypeForCallingConv rather than using CCPromoteToType in the td file
      
      Previously we tried to promote these to xmm/ymm/zmm by promoting
      in the X86CallingConv.td file. But this breaks when we run out
      of xmm/ymm/zmm registers and need to fall back to memory. We end
      up trying to create a non-sensical scalar to vector. This lead
      to an assertion. The new tests in avx512-calling-conv.ll all
      trigger this assertion.
      
      Since we really want to treat these types like we do on avx2,
      it seems better to promote them before the calling convention
      code gets involved. Except when the calling convention is one
      that passes the vXi1 type in a k register.
      
      The changes in avx512-regcall-Mask.ll are because we indicated
      that xmm/ymm/zmm types should be passed indirectly for the
      Win64 ABI before we go to the common lines that promoted the
      vXi1 types. This caused the promoted types to be picked up by
      the default calling convention code. Now we promote them earlier
      so they get passed indirectly as though they were xmm/ymm/zmm.
      
      Differential Revision: https://reviews.llvm.org/D75154
      eadea786
  2. Mar 04, 2020
Loading