Skip to content
Snippets Groups Projects
  1. Mar 07, 2019
  2. Feb 26, 2019
    • Alex Crichton's avatar
      Merge pull request #9 from alexcrichton/another · 38ad31bd
      Alex Crichton authored
      Another upstream merge + build system fix
      38ad31bd
    • Alex Crichton's avatar
      Delete version check for clang-cl · f6605a6d
      Alex Crichton authored
      We have a 19.0 version but it's checking for 19.0.2xxx, so presumably
      it's just a bug in the compiler check and we should be running alright.
      For now just assume that, delete this, and see if this is fixed by the
      next LLVM release.
      f6605a6d
    • Alex Crichton's avatar
    • Hans Wennborg's avatar
      Merging r354733: · e56517b2
      Hans Wennborg authored
      ------------------------------------------------------------------------
      r354733 | nikic | 2019-02-23 19:59:01 +0100 (Sat, 23 Feb 2019) | 10 lines
      
      [WebAssembly] Fix select of and (PR40805)
      
      Fixes https://bugs.llvm.org/show_bug.cgi?id=40805 introduced by
      patterns added in D53676.
      
      I'm removing the patterns entirely here, as they are not correct
      in the general case. If necessary something more specific can be
      added in the future.
      
      Differential Revision: https://reviews.llvm.org/D58575
      ------------------------------------------------------------------------
      
      llvm-svn: 354860
      e56517b2
    • Hans Wennborg's avatar
      Merging r354723: · 35782c56
      Hans Wennborg authored
      ------------------------------------------------------------------------
      r354723 | brad | 2019-02-23 08:21:19 +0100 (Sat, 23 Feb 2019) | 3 lines
      
      Remove OpenBSD case for old system libstdc++ header path as OpenBSD
      has switched to libc++.
      
      ------------------------------------------------------------------------
      
      llvm-svn: 354859
      35782c56
    • Hans Wennborg's avatar
      Merging r354721: · 319e7dfd
      Hans Wennborg authored
      ------------------------------------------------------------------------
      r354721 | brad | 2019-02-23 07:19:28 +0100 (Sat, 23 Feb 2019) | 4 lines
      
      Remove sanitizer context workaround no longer necessary
      
      The base linker is now lld.
      
      ------------------------------------------------------------------------
      
      llvm-svn: 354858
      319e7dfd
    • Hans Wennborg's avatar
      Merging r354756: · e745d6dd
      Hans Wennborg authored
      ------------------------------------------------------------------------
      r354756 | ctopper | 2019-02-24 20:33:37 +0100 (Sun, 24 Feb 2019) | 36 lines
      
      [X86] Fix tls variable lowering issue with large code model
      
      Summary:
      The problem here is the lowering for tls variable. Below is the DAG for the code.
      SelectionDAG has 11 nodes:
      
      t0: ch = EntryToken
            t8: i64,ch = load<(load 8 from `i8 addrspace(257)* null`, addrspace 257)> t0, Constant:i64<0>, undef:i64
              t10: i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=10]
            t11: i64,ch = load<(load 8 from got)> t0, t10, undef:i64
          t12: i64 = add t8, t11
        t4: i32,ch = load<(dereferenceable load 4 from @x)> t0, t12, undef:i64
      t6: ch = CopyToReg t0, Register:i32 %0, t4
      And when mcmodel is large, below instruction can NOT be folded.
      
        t10: i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=10]
      t11: i64,ch = load<(load 8 from got)> t0, t10, undef:i64
      So "t11: i64,ch = load<(load 8 from got)> t0, t10, undef:i64" is lowered to " Morphed node: t11: i64,ch = MOV64rm<Mem:(load 8 from got)> t10, TargetConstant:i8<1>, Register:i64 $noreg, TargetConstant:i32<0>, Register:i32 $noreg, t0"
      
      When llvm start to lower "t10: i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=10]", it fails.
      
      The patch is to fold the load and X86ISD::WrapperRIP.
      
      Fixes PR26906
      
      Patch by LuoYuanke
      
      Reviewers: craig.topper, rnk, annita.zhang, wxiao3
      
      Reviewed By: rnk
      
      Subscribers: llvm-commits
      
      Tags: #llvm
      
      Differential Revision: https://reviews.llvm.org/D58336
      ------------------------------------------------------------------------
      
      llvm-svn: 354857
      e745d6dd
    • Hans Wennborg's avatar
      Merging r354764: · ee57e9e1
      Hans Wennborg authored
      ------------------------------------------------------------------------
      r354764 | lebedevri | 2019-02-25 08:39:07 +0100 (Mon, 25 Feb 2019) | 123 lines
      
      [XRay][tools] Revert "Use Support/JSON.h in llvm-xray convert"
      
      Summary:
      This reverts D50129 / rL338834: [XRay][tools] Use Support/JSON.h in llvm-xray convert
      
      Abstractions are great.
      Readable code is great.
      JSON support library is a *good* idea.
      
      However unfortunately, there is an internal detail that one needs
      to be aware of in `llvm::json::Object` - it uses `llvm::DenseMap`.
      So for **every** `llvm::json::Object`, even if you only store a single `int`
      entry there, you pay the whole price of `llvm::DenseMap`.
      
      Unfortunately, it matters for `llvm-xray`.
      
      I was trying to analyse the `llvm-exegesis` analysis mode performance,
      and for that i wanted to view the LLVM X-Ray log visualization in Chrome
      trace viewer. And the `llvm-xray convert` is sluggish, and sometimes
      even ended up being killed by OOM.
      
      `xray-log.llvm-exegesis.lwZ0sT` was acquired from `llvm-exegesis`
      (compiled with ` -fxray-instruction-threshold=128`)
      analysis mode over `-benchmarks-file` with 10099 points (one full
      latency measurement set), with normal runtime of 0.387s.
      
      Timings:
      Old: (copied from D58580)
      ```
      $ perf stat -r 5 ./bin/llvm-xray convert -sort -symbolize -instr_map=./bin/llvm-exegesis -output-format=trace_event -output=/tmp/trace.yml xray-log.llvm-exegesis.lwZ0sT
      
       Performance counter stats for './bin/llvm-xray convert -sort -symbolize -instr_map=./bin/llvm-exegesis -output-format=trace_event -output=/tmp/trace.yml xray-log.llvm-exegesis.lwZ0sT' (5 runs):
      
                21346.24 msec task-clock                #    1.000 CPUs utilized            ( +-  0.28% )
                     314      context-switches          #   14.701 M/sec                    ( +- 59.13% )
                       1      cpu-migrations            #    0.037 M/sec                    ( +-100.00% )
                 2181354      page-faults               # 102191.251 M/sec                  ( +-  0.02% )
             85477442102      cycles                    # 4004415.019 GHz                   ( +-  0.28% )  (83.33%)
             14526427066      stalled-cycles-frontend   #   16.99% frontend cycles idle     ( +-  0.70% )  (83.33%)
             32371533721      stalled-cycles-backend    #   37.87% backend cycles idle      ( +-  0.27% )  (33.34%)
             67896890228      instructions              #    0.79  insn per cycle
                                                        #    0.48  stalled cycles per insn  ( +-  0.03% )  (50.00%)
             14592654840      branches                  # 683631198.653 M/sec               ( +-  0.02% )  (66.67%)
               212207534      branch-misses             #    1.45% of all branches          ( +-  0.94% )  (83.34%)
      
                 21.3502 +- 0.0585 seconds time elapsed  ( +-  0.27% )
      ```
      New:
      ```
      $ perf stat -r 9 ./bin/llvm-xray convert -sort -symbolize -instr_map=./bin/llvm-exegesis -output-format=trace_event -output=/tmp/trace.yml xray-log.llvm-exegesis.lwZ0sT
      
       Performance counter stats for './bin/llvm-xray convert -sort -symbolize -instr_map=./bin/llvm-exegesis -output-format=trace_event -output=/tmp/trace.yml xray-log.llvm-exegesis.lwZ0sT' (9 runs):
      
                 7178.38 msec task-clock                #    1.000 CPUs utilized            ( +-  0.26% )
                     182      context-switches          #   25.402 M/sec                    ( +- 28.84% )
                       0      cpu-migrations            #    0.046 M/sec                    ( +- 70.71% )
                   33701      page-faults               # 4694.994 M/sec                    ( +-  0.88% )
             28761053971      cycles                    # 4006833.933 GHz                   ( +-  0.26% )  (83.32%)
              2028297997      stalled-cycles-frontend   #    7.05% frontend cycles idle     ( +-  1.61% )  (83.32%)
             10773154901      stalled-cycles-backend    #   37.46% backend cycles idle      ( +-  0.38% )  (33.36%)
             36199132874      instructions              #    1.26  insn per cycle
                                                        #    0.30  stalled cycles per insn  ( +-  0.03% )  (50.02%)
              6434504227      branches                  # 896420204.421 M/sec               ( +-  0.03% )  (66.68%)
                73355176      branch-misses             #    1.14% of all branches          ( +-  1.46% )  (83.33%)
      
                  7.1807 +- 0.0190 seconds time elapsed  ( +-  0.26% )
      ```
      
      So using `llvm::json` nearly triples run-time on that test case.
      (+3x is times, not percent.)
      
      Memory:
      Old:
      ```
      total runtime: 39.88s.
      bytes allocated in total (ignoring deallocations): 79.07GB (1.98GB/s)
      calls to allocation functions: 33267816 (834135/s)
      temporary memory allocations: 5832298 (146235/s)
      peak heap memory consumption: 9.21GB
      peak RSS (including heaptrack overhead): 147.98GB
      total memory leaked: 1.09MB
      ```
      New:
      ```
      total runtime: 17.42s.
      bytes allocated in total (ignoring deallocations): 5.12GB (293.86MB/s)
      calls to allocation functions: 21382982 (1227284/s)
      temporary memory allocations: 232858 (13364/s)
      peak heap memory consumption: 350.69MB
      peak RSS (including heaptrack overhead): 2.55GB
      total memory leaked: 79.95KB
      ```
      Diff:
      ```
      total runtime: -22.46s.
      bytes allocated in total (ignoring deallocations): -73.95GB (3.29GB/s)
      calls to allocation functions: -11884834 (529155/s)
      temporary memory allocations: -5599440 (249307/s)
      peak heap memory consumption: -8.86GB
      peak RSS (including heaptrack overhead): 0B
      total memory leaked: -1.01MB
      ```
      So using `llvm::json` increases *peak* memory consumption on *this* testcase ~+27x.
      And total allocation count +15x. Both of these numbers are times, *not* percent.
      
      And note that memory usage is clearly unbound with `llvm::json`, it directly depends
      on the length of the log, so peak memory consumption is always increasing.
      This isn't so with the dumb code, there is no accumulating memory consumption,
      peak memory consumption is fixed. Naturally, that means it will handle *much*
      larger logs without OOM'ing.
      
      Readability is good, but the price is simply unacceptable here.
      Too bad none of this analysis was done as part of the development/review D50129 itself.
      
      Reviewers: dberris, kpw, sammccall
      
      Reviewed By: dberris
      
      Subscribers: riccibruno, hans, courbet, jdoerfert, llvm-commits
      
      Tags: #llvm
      
      Differential Revision: https://reviews.llvm.org/D58584
      ------------------------------------------------------------------------
      
      llvm-svn: 354856
      ee57e9e1
    • Hans Wennborg's avatar
      ReleaseNotes: ARM64 SEH, pointed out by David Major · 0777c34a
      Hans Wennborg authored
      llvm-svn: 354855
      0777c34a
  3. Feb 25, 2019
  4. Feb 22, 2019
  5. Feb 21, 2019
  6. Feb 20, 2019
    • Hans Wennborg's avatar
      Merging r354402: · cd76cbaa
      Hans Wennborg authored
      ------------------------------------------------------------------------
      r354402 | eugenis | 2019-02-20 00:41:42 +0100 (Wed, 20 Feb 2019) | 3 lines
      
      [msan] Fix name_to_handle_at test on overlayfs.
      
      Udev supports name_to_handle_at. Use /dev/null instead of /bin/cat.
      ------------------------------------------------------------------------
      
      llvm-svn: 354460
      cd76cbaa
    • Hans Wennborg's avatar
      Merging r354351: · 83dcd05f
      Hans Wennborg authored
      ------------------------------------------------------------------------
      r354351 | hans | 2019-02-19 17:58:25 +0100 (Tue, 19 Feb 2019) | 12 lines
      
      Remove extraneous space in MSVC-style diagnostic output
      
      There was an extra space between the file location and the diagnostic
      message:
      
        /tmp/a.c(1,12):  warning: unused parameter 'unused'
      
      the tests didn't catch this due to FileCheck not running in --strict-whitespace mode.
      
      Reported by Marco: http://lists.llvm.org/pipermail/cfe-dev/2019-February/061326.html
      
      Differential revision: https://reviews.llvm.org/D58377
      ------------------------------------------------------------------------
      
      llvm-svn: 354459
      83dcd05f
    • Hans Wennborg's avatar
      ReleaseNotes: all PowerPC changes · b936e1cf
      Hans Wennborg authored
      llvm-svn: 354458
      b936e1cf
    • Hans Wennborg's avatar
      ReleaseNotes: AArch64 tiny code model · e4bde922
      Hans Wennborg authored
      llvm-svn: 354457
      e4bde922
Loading