and though bugs are the bane of my existence, rest assured the wretched thing will get the best of care here

  1. 04 Jun, 2018 1 commit
    • Tom Stellard's avatar
      Merging r333467: · f3e10f8b
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r333467 | marshall | 2018-05-29 15:25:42 -0700 (Tue, 29 May 2018) | 1 line
      
      Fix embarrasing typo in uncaught_exceptions. Update tests to really test this. Thanks to Peter Klotz for calling my attention to this.
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333910
      f3e10f8b
  2. 31 May, 2018 1 commit
    • Tom Stellard's avatar
      Merging r322030: · 742e3215
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r322030 | rsmith | 2018-01-08 13:46:42 -0800 (Mon, 08 Jan 2018) | 3 lines
      
      PR35862: Suppress -Wmissing-variable-declarations warning on inline variables,
      variable templates, and instantiations thereof.
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333623
      742e3215
  3. 30 May, 2018 10 commits
    • Tom Stellard's avatar
      Merging r326358: · fa5423e8
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r326358 | dim | 2018-02-28 12:04:21 -0800 (Wed, 28 Feb 2018) | 29 lines
      
      Fix llvm-config --system-libs output on FreeBSD and NetBSD
      
      Summary:
      For various reasons, CMake's detection mechanism for `backtrace()`
      returns an absolute path `/usr/lib/libexecinfo.so` on FreeBSD and
      NetBSD.
      
      Since `tools/llvm-config/CMakeLists.txt` only checks if system
      libraries start with `-`, this causes `llvm-config --system-libs` to
      produce the following incorrect output:
      
      ```
      -lrt -l/usr/lib/libexecinfo.so -ltinfo -lpthread -lz -lm
      ```
      
      Fix it by removing the path and the `lib` prefix, to make it look like a
      regular short library name, suitable for appending to a `-l` link flag.
      
      This also fixes the `Bindings/Go/go.test` test case, since that always
      died with "unable to find library -l/usr/lib/libexecinfo.so".
      
      Reviewers: chandlerc, emaste, joerg, krytarowski
      
      Reviewed By: krytarowski
      
      Subscribers: hans, bdrewery, mgorny, hintonda, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D42702
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333579
      fa5423e8
    • Tom Stellard's avatar
      Merging r328798: · 699cfaec
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r328798 | haicheng | 2018-03-29 09:01:26 -0700 (Thu, 29 Mar 2018) | 37 lines
      
      [JumpThreading] Don't select an edge that we know we can't thread
      
      In r312664 (D36404), JumpThreading stopped threading edges into
      loop headers. Unfortunately, I observed a significant performance
      regression as a result of this change. Upon further investigation,
      the problematic pattern looked something like this (after
      many high level optimizations):
      
      while (true) {
          bool cond = ...;
          if (!cond) {
              <body>
          }
          if (cond)
              break;
      }
      
      Now, naturally we want jump threading to essentially eliminate the
      second if check and hook up the edges appropriately. However, the
      above mentioned change, prevented it from doing this because it would
      have to thread an edge into the loop header.
      
      Upon further investigation, what is happening is that since both branches
      are threadable, JumpThreading picks one of them at arbitrarily. In my
      case, because of the way that the IR ended up, it tended to pick
      the one to the loop header, bailing out immediately after. However,
      if it had picked the one to the exit block, everything would have
      worked out fine (because the only remaining branch would then be folded,
      not thraded which is acceptable).
      
      Thus, to fix this problem, we can simply eliminate loop headers from
      consideration as possible threading targets earlier, to make sure that
      if there are multiple eligible branches, we can still thread one of
      the ones that don't target a loop header.
      
      Patch by Keno Fischer!
      Differential Revision: https://reviews.llvm.org/D42260
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333577
      699cfaec
    • Tom Stellard's avatar
      Merging r333497: · 8d692766
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r333497 | ctopper | 2018-05-29 20:38:15 -0700 (Tue, 29 May 2018) | 5 lines
      
      [X86] Fix the names of a bunch of icelake intrinsics.
      
      Mostly this fixes the names of all the 128-bit intrinsics to start with _mm_ instead of _mm128_ as is the convention and what the Intel docs say.
      
      This also fixes the name of the bitshuffle intrinsics to say epi64 for 128 and 256 bit versions.
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333575
      8d692766
    • Tom Stellard's avatar
      Merging r326476: · 06815bf8
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r326476 | mstorsjo | 2018-03-01 12:22:57 -0800 (Thu, 01 Mar 2018) | 7 lines
      
      [RecordLayout] Only assert that fundamental type sizes are power of two on MSVC
      
      Make types with sizes that aren't a power of two an error (that can
      be disabled) in structs with ms_struct layout, except on mingw where
      the situation is quite likely to occur and GCC handles it silently.
      
      Differential Revision: https://reviews.llvm.org/D43908
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333571
      06815bf8
    • Tom Stellard's avatar
      Merging r326173: · ba3c53d0
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r326173 | mstorsjo | 2018-02-26 22:27:06 -0800 (Mon, 26 Feb 2018) | 17 lines
      
      [RecordLayout] Don't align to non-power-of-2 sizes when using -mms-bitfields
      
      When targeting GNU/MinGW for i386, the size of the "long double" data
      type is 12 bytes (while it is 8 bytes in MSVC). When building
      with -mms-bitfields to have struct layouts match MSVC, data types
      are laid out in a struct with alignment according to their size.
      However, this doesn't make sense for the long double type, since
      it doesn't match MSVC at all, and aligning to a non-power-of-2
      size triggers other asserts later.
      
      This matches what GCC does, aligning a long double to 4 bytes
      in structs on i386 even when -mms-bitfields is specified.
      
      This fixes asserts when using the max_align_t data type when
      building for MinGW/i386 with the -mms-bitfields flag.
      
      Differential Revision: https://reviews.llvm.org/D43734
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333569
      ba3c53d0
    • Tom Stellard's avatar
      Merging r326235: · e15bb83e
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r326235 | mstorsjo | 2018-02-27 11:42:19 -0800 (Tue, 27 Feb 2018) | 6 lines
      
      [MinGW, CrossWindows] Allow passing -static together with -shared
      
      In these combinations, link a DLL as usual, but pass -Bstatic instead
      of -Bdynamic to indicate prefering static libraries.
      
      Differential Revision: https://reviews.llvm.org/D43811
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333566
      e15bb83e
    • Tom Stellard's avatar
      Merging r329300: · 3bc2d0a6
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r329300 | manojgupta | 2018-04-05 08:29:52 -0700 (Thu, 05 Apr 2018) | 16 lines
      
      Disable -fmerge-all-constants as default.
      
      Summary:
      "-fmerge-all-constants" is a non-conforming optimization and should not
      be the default. It is also causing miscompiles when building Linux
      Kernel (https://lkml.org/lkml/2018/3/20/872).
      
      Fixes PR18538.
      
      Reviewers: rjmccall, rsmith, chandlerc
      
      Reviewed By: rsmith, chandlerc
      
      Subscribers: srhines, cfe-commits
      
      Differential Revision: https://reviews.llvm.org/D45289
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333564
      3bc2d0a6
    • Tom Stellard's avatar
      Merging r330345: · 374c27a4
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r330345 | kparzysz | 2018-04-19 10:26:46 -0700 (Thu, 19 Apr 2018) | 8 lines
      
      [if-converter] Handle BBs that terminate in ret during diamond conversion
      
      This fixes https://llvm.org/PR36825.
      
      Original patch by Valentin Churavy (D45218).
      
      Differential Revision: https://reviews.llvm.org/D45731
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333561
      374c27a4
    • Tom Stellard's avatar
      Merging r330331: · 64dcc854
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r330331 | erichkeane | 2018-04-19 07:27:05 -0700 (Thu, 19 Apr 2018) | 14 lines
      
      Fix __attribute__((force_align_arg_pointer)) misalignment bug
      
      The force_align_arg_pointer attribute was using a hardcoded 16-byte
      alignment value which in combination with -mstack-alignment=32 (or
      larger) would produce a misaligned stack which could result in crashes
      when accessing stack buffers using aligned AVX load/store instructions.
      
      Fix the issue by using the "stackrealign" function attribute instead
      of using a hardcoded 16-byte alignment.
      
      Patch By: Gramner
      
      Differential Revision: https://reviews.llvm.org/D45812
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333511
      64dcc854
    • Tom Stellard's avatar
      Merging r327863: · aaa7a7a2
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r327863 | sepavloff | 2018-03-19 09:13:43 -0700 (Mon, 19 Mar 2018) | 12 lines
      
      [Driver] Avoid invalidated iterator in insertTargetAndModeArgs
      
      Doing an .insert() can potentially invalidate iterators by reallocating the
      vector's storage. When all the stars align just right, this causes segfaults
      or glibc aborts.
      
      Gentoo Linux bug (crashes while building Chromium): https://bugs.gentoo.org/650082.
      
      Patch by Hector Martin!
      
      Differential Revision: https://reviews.llvm.org/D44607
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333507
      aaa7a7a2
  4. 29 May, 2018 5 commits
    • Tom Stellard's avatar
      Merging r332302: · c4476884
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r332302 | kfischer | 2018-05-14 15:05:01 -0700 (Mon, 14 May 2018) | 15 lines
      
      [InstCombine] fix crash due to ignored addrspacecast
      
      Summary:
      Part of the InstCombine code for simplifying GEPs looks through
      addrspacecasts. However, this was done by updating a variable
      also used by the next transformation, for marking GEPs as
      inbounds. This led to replacing a GEP with a similar instruction
      in a different addrspace, which caused an assertion failure in RAUW.
      
      This caused julia issue https://github.com/JuliaLang/julia/issues/27055
      
      Patch by Jeff Bezanson <jeff@juliacomputing.com>
      
      Reviewed By: arsenm
      Differential Revision: https://reviews.llvm.org/D46722
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333477
      c4476884
    • Tom Stellard's avatar
      Merging r328885: · 75f4129b
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r328885 | timshen | 2018-03-30 10:51:03 -0700 (Fri, 30 Mar 2018) | 14 lines
      
      [NVPTX] Enable StructuredCFG for NVPTX
      
      Summary:
      Make NVPTX require structured CFG. Added a temporary flag to
      "roll back" the behavior for easy deployment.
      
      Combined with D45008, this fixes several internal Nvidia GPU test
      failures that we suspect to be ptxas miscompiles (PR27738).
      
      Reviewers: jlebar
      
      Subscribers: jholewinski, sanjoy, llvm-commits, hiraditya
      
      Differential Revision: https://reviews.llvm.org/D45070
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333475
      75f4129b
    • Tom Stellard's avatar
      Merging r328884: · f0350e65
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r328884 | timshen | 2018-03-30 10:51:00 -0700 (Fri, 30 Mar 2018) | 19 lines
      
      [BlockPlacement] Disable block placement tail duplciation in structured CFG.
      
      Summary:
      Tail duplication easily breaks the structure of CFG, e.g. duplicating on
      a region entry. If the structure is intended to be preserved, then we
      may want to configure tail duplication, or disable it for structured
      CFG. From our benchmark results disabling it doesn't cause performance
      regression.
      
      Notice that this currently affects AMDGPU backend. In the next patch, I
      also plan to turn on requiresStructuredCFG for NVPTX.
      
      All unit tests still pass.
      
      Reviewers: jlebar, arsenm
      
      Subscribers: jholewinski, sanjoy, wdng, tpr, hiraditya, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D45008
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333474
      f0350e65
    • Tom Stellard's avatar
      Merging r332682 and r332694: · 3300c5ae
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r332682 | kfischer | 2018-05-17 18:03:01 -0700 (Thu, 17 May 2018) | 21 lines
      
      [X86DomainReassignment] Don't compare stack-allocated values by address
      
      Summary:
      The Closure allocated in the main loop is allocated on the stack. However,
      later in the code its address is taken (and used for comparisons). This
      obviously doesn't work. In fact, the Closure will get the same stack address
      during every loop iteration, rendering the check that intended to identify
      Closure conflicts entirely ineffective. Fix this bug by giving every Closure
      a unique ID and using that for comparison. Alternatively, we could heap
      allocate the closure object.
      
      Fixes PR37396
      Fixes JuliaLang/julia#27032
      
      Reviewers: craig.topper, guyblank
      
      Reviewed By: craig.topper
      
      Subscribers: vchuravy, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D46800
      ```
      
      ---------------------------------------------------------------------
      
      ------------------------------------------------------------------------
      r332694 | kfischer | 2018-05-17 21:36:38 -0700 (Thu, 17 May 2018) | 15 lines
      
      [X86DomainReassignment] Hopefully fix buildbot failure
      
      The Darwin build bot failed with:
      ```
      llc -mcpu=skylake-avx512 -mtriple=x86_64-unknown-linux-gnu domain-reassignment-test.ll -o - | llvm-mc
      --
      Exit Code: 134
      
      Command Output (stderr):
      --
      Assertion failed: (MAI->hasSingleParameterDotFile()), function EmitFileDirective, file lib/MC/MCAsmStreamer.cpp, line 1087.
      ```
      
      Looks like this is because the `llvm-mc` command was missing a triple
      directive and defaulting to MachO. Add the triple option.
      ------------------------------------------------------------------------
      
      llvm-svn: 333470
      3300c5ae
    • Tom Stellard's avatar
      Merging r332680: · 2875d5f8
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r332680 | kfischer | 2018-05-17 17:40:52 -0700 (Thu, 17 May 2018) | 13 lines
      
      [X86DomainReassignment] Don't delete IMPLICIT_DEF nodes
      
      Summary:
      We cannot simply delete IMPLICIT_DEF nodes. They may be used
      later (e.g. by a PHI) and deleting them will cause later passes (e.g.
      LiveVariables) to crash. However, it seems fine to ignore them for
      purposes of the domain reassignment (as we do with PHI).
      
      Fixes PR37430
      Fixes JuliaLang/julia#27080
      
      Reviewed By: craig.topper
      Differential Revision: https://reviews.llvm.org/D46797
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333469
      2875d5f8
  5. 24 May, 2018 1 commit
    • Geoff Berry's avatar
      Merging r330976: · e8deffb8
      Geoff Berry authored
      ```---------------------------------------------------------------------
      r330976 | gberry | 2018-04-26 14:50:45 -0400 (Thu, 26 Apr 2018) | 15 lines
      
      [AArch64] Fix scavenged spill slot base when stack realignment required.
      
      Summary:
      Use the FP for scavenged spill slot accesses to prevent corruption of
      the callee-save region when the SP is re-aligned.
      
      Based on problem and patch reported by @paulwalker-arm
      
      This is an alternative to solution proposed in D45770
      
      Reviewers: t.p.northover, paulwalker-arm, thegameg, javed.absar
      
      Subscribers: qcolombet, mcrosier, paulwalker-arm, kristof.beyls, rengolin, javed.absar, llvm-commits
      
      Differential Revision: https://reviews.llvm.org/D46063
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 333223
      e8deffb8
  6. 22 May, 2018 9 commits
  7. 21 May, 2018 2 commits
  8. 18 May, 2018 4 commits
    • Tom Stellard's avatar
      Merging r330037: · a4be93f6
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r330037 | sdardis | 2018-04-13 09:09:07 -0700 (Fri, 13 Apr 2018) | 21 lines
      
      [mips] Materialize constants for multiplication
      
      Previously, the MIPS backend would alwyas break down constant multiplications
      into a series of shifts, adds, and subs. This patch changes that so the cost of
      doing so is estimated.
      
      The cost is estimated against worst case constant materialization and retrieving
      the results from the HI/LO registers.
      
      For cases where the value type of the multiplication is not legal, the cost of
      legalization is estimated and is accounted for before performing the
      optimization of breaking down the constant
      
      This resolves PR36884.
      
      Thanks to npl for reporting the issue!
      
      Reviewers: abeserminji, smaksimovic
      
      Differential Revision: https://reviews.llvm.org/D45316
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 332782
      a4be93f6
    • Tom Stellard's avatar
      Merging r329268: · 58d8ab30
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r329268 | sdardis | 2018-04-05 03:30:17 -0700 (Thu, 05 Apr 2018) | 2 lines
      
      [mips] Regenerate test before posting patch for constant multiplication (NFC)
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 332778
      58d8ab30
    • Tom Stellard's avatar
      Merging r324885: · c3478f3a
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r324885 | atanasyan | 2018-02-12 04:21:55 -0800 (Mon, 12 Feb 2018) | 8 lines
      
      [mips] Fix 'l' constraint handling for types smaller than 32 bits
      
      In case of correct using of the 'l' constraint llvm now generates valid
      code; otherwise it shows an error message. Initially these triggers an
      assertion.
      
      This commit is the same as r324869 with fixed the test's file name.
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 332776
      c3478f3a
    • Tom Stellard's avatar
      Merging r322266: · a6d704f4
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r322266 | smaksimovic | 2018-01-11 02:07:47 -0800 (Thu, 11 Jan 2018) | 7 lines
      
      [Mips] Handle one byte unsupported relocations
      
      Fail gracefully instead of crashing upon encountering
      this type of relocation.
      
      Differential revision: https://reviews.llvm.org/D41857
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 332765
      a6d704f4
  9. 17 May, 2018 7 commits
    • Tom Stellard's avatar
      Merging r331990: · 083bcf84
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r331990 | whitequark | 2018-05-10 08:05:47 -0700 (Thu, 10 May 2018) | 15 lines
      
      [PR37339] Fix assertion in FunctionComparator::cmpInlineAsm
      
      Fixes bug https://bugs.llvm.org/show_bug.cgi?id=37339.
      
      InlineAsm is only uniqued if the FunctionTypes are exactly the
      same, while cmpTypes() for example considers all pointer types
      in the default address space to be the same. For this reason
      the end of cmpInlineAsm() can be reached.
      
      This patch replaces the unreachable assertion with a check that
      the function types are not identical.
      
      Differential Revision: https://reviews.llvm.org/D46495
      
      Reviewers: jfb
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 332678
      083bcf84
    • Tom Stellard's avatar
      Merging r332342: · e1b276e9
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r332342 | whitequark | 2018-05-15 04:31:07 -0700 (Tue, 15 May 2018) | 23 lines
      
      [MergeFunctions] Fix merging of small weak functions
      
      When two interposable functions are merged, we cannot replace
      uses and have to emit calls to a common internal function. However,
      writeThunk() will not actually emit a thunk if the function is too
      small. This leaves us in a broken state where mergeTwoFunctions
      already rewired the functions, but writeThunk doesn't do anything.
      
      This patch changes the implementation so that:
      
       * writeThunk() does just that.
       * The direct replacement of calls is moved into mergeTwoFunctions()
         into the non-interposable case only.
       * isThunkProfitable() is extracted and will be called for
         the non-iterposable case always, and in the interposable case
         only if uses are still left after replacement.
      
      This issue has been introduced in https://reviews.llvm.org/D34806,
      where the code for checking thunk profitability has been moved.
      
      Differential Revision: https://reviews.llvm.org/D46804
      
      Reviewed By: whitequark
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 332662
      e1b276e9
    • Tom Stellard's avatar
      Merging r324581: · c3fd54c8
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r324581 | sjoerdmeijer | 2018-02-08 00:39:05 -0800 (Thu, 08 Feb 2018) | 12 lines
      
      [AArch64] Don't materialize 0 with "fmov h0, .." when FullFP16 is not supported
      
      We were generating "fmov h0, wzr" instructions when FullFP16 is not enabled.
      I've not added any tests, because the problem was visible in:
      test/CodeGen/AArch64/arm64-zero-cycle-zeroing.ll,
      which I had to change: I don't think Cyclone has FullFP16 enabled
      by default, so it shouldn't be using this v8.2a instruction.
      
      I've also removed these rdar tags, please shout if there are any objections.
      
      Differential Revision: https://reviews.llvm.org/D43020
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 332655
      c3fd54c8
    • Tom Stellard's avatar
      Merging r323816: · 8af7f5b6
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r323816 | evandro | 2018-01-30 13:14:11 -0800 (Tue, 30 Jan 2018) | 5 lines
      
      [AArch64] Expand testing of zero cycle zeroing
      
      Make sure that r321824 doesn't change zeroing.
      
      Differential revision: https://reviews.llvm.org/D42089
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 332651
      8af7f5b6
    • Tom Stellard's avatar
      Merging r330927: · 489394b2
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r330927 | sepavloff | 2018-04-26 01:08:25 -0700 (Thu, 26 Apr 2018) | 2 lines
      
      Make test more platform neutral
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 332650
      489394b2
    • Tom Stellard's avatar
      Merging r330926: · ac707257
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r330926 | sepavloff | 2018-04-25 23:28:47 -0700 (Wed, 25 Apr 2018) | 9 lines
      
      [ConfigFiles] Update argument strings when merging argrument lists
      
      Implementation of `InputArgList` assumes its field `ArgStrings` contains
      strings for each argument exactly in the same order. This condition was
      broken when arguments from config file and from invocation were merged.
      
      This change fixes https://bugs.llvm.org/show_bug.cgi?id=37196 (Clang
      config files can crash argument handling).
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 332649
      ac707257
    • Tom Stellard's avatar
      Merging r332444: · eb4d3d30
      Tom Stellard authored
      ```---------------------------------------------------------------------
      r332444 | psmith | 2018-05-16 02:33:25 -0700 (Wed, 16 May 2018) | 20 lines
      
      [AArch64] Support "S" inline assembler constraint
      
      This patch re-introduces the "S" inline assembler constraint. This matches
      an absolute symbolic address or a label reference. The primary use case is
      
      asm("adrp %0, %1\n\t"
          "add %0, %0, :lo12:%1" : "=r"(addr) : "S"(&var));
      
      I say re-introduces as it seems like "S" was implemented in the original
      AArch64 backend, but it looks like it wasn't carried forward to the merged
      backend. The original implementation had A and L modifiers that could be
      used to print ":lo12:" to the string. It looks like gcc doesn't use these
      and :lo12: is expected to be written in the inline assembly string so I've
      not implemented A and L. Clang already supports the S modifier.
      
      Fixes PR37180
      
      Differential Revision: https://reviews.llvm.org/D46745
      ```
      
      ---------------------------------------------------------------------
      
      llvm-svn: 332644
      eb4d3d30