------------------------------------------------------------------------
r354505 | ibiryukov | 2019-02-20 20:08:06 +0100 (Wed, 20 Feb 2019) | 13 lines

[clangd] Store index in '.clangd/index' instead of '.clangd-index'

Summary: To take up the .clangd folder for other potential uses in the future.

Reviewers: kadircet, sammccall

Reviewed By: kadircet

Subscribers: ioeric, MaskRay, jkorous, arphaman, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D58440
------------------------------------------------------------------------

llvm-svn: 354981

------------------------------------------------------------------------
r353422 | kadircet | 2019-02-07 17:04:30 +0100 (Thu, 07 Feb 2019) | 18 lines

[clangd] Reduce number of threads used by BackgroundIndex to number of physical cores.

Summary:
clangd is using as many threads as logical cores for BackgroundIndex
by default. We observed that it increases latency of foreground tasks.

This patch aims to change that default to number of physical cores to get rid of
that extra latency.

Reviewers: ilya-biryukov

Reviewed By: ilya-biryukov

Subscribers: ioeric, MaskRay, jkorous, arphaman, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D57819
------------------------------------------------------------------------

llvm-svn: 354980

llvm-svn: 354979

llvm-svn: 354977

llvm-svn: 354973

llvm-svn: 354971

------------------------------------------------------------------------
r354968 | hans | 2019-02-27 14:11:37 +0100 (Wed, 27 Feb 2019) | 1 line

AttrDocs.td: fix broken bullet-point indentation
------------------------------------------------------------------------

llvm-svn: 354970

llvm-svn: 354967

------------------------------------------------------------------------
r354207 | whitequark | 2019-02-16 23:33:10 +0100 (Sat, 16 Feb 2019) | 16 lines

[bindings/go] Fix building on 32-bit systems (ARM etc.)

Summary:
The patch in https://reviews.llvm.org/D53883 (by me) fails to build on 32-bit systems like ARM. Fix the array size to be less ridiculously large. 2<<20 should still be enough for all practical purposes.

Bug: https://bugs.llvm.org/show_bug.cgi?id=40426

Reviewers: whitequark, pcc

Reviewed By: whitequark

Subscribers: javed.absar, kristof.beyls, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58030
------------------------------------------------------------------------

llvm-svn: 354956

By Jonathan Metzman!

Differential revision: https://reviews.llvm.org/D58676

llvm-svn: 354892

------------------------------------------------------------------------
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

------------------------------------------------------------------------
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

------------------------------------------------------------------------
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

------------------------------------------------------------------------
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

------------------------------------------------------------------------
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

llvm-svn: 354855

Differential Revision: https://reviews.llvm.org/D58504

llvm-svn: 354799

llvm-svn: 354794

llvm-svn: 354660

llvm-svn: 354659

llvm-svn: 354583

llvm-svn: 354582

------------------------------------------------------------------------
r354497 | tstellar | 2019-02-20 19:43:45 +0100 (Wed, 20 Feb 2019) | 16 lines

AArch64/test: Add check for function name to machine-outliner-bad-adrp.mir

Summary:
This test was failing in one of our setups because the generated ModuleID
had the full path of the test file and that path contained the string
BL.

Reviewers: t.p.northover, jpaquette, paquette

Reviewed By: paquette

Subscribers: javed.absar, kristof.beyls, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58217
------------------------------------------------------------------------

llvm-svn: 354555

llvm-svn: 354554

------------------------------------------------------------------------
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

------------------------------------------------------------------------
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

llvm-svn: 354458

llvm-svn: 354457

llvm-svn: 354450

llvm-svn: 354448

------------------------------------------------------------------------
r354422 | tstellar | 2019-02-20 02:40:35 +0100 (Wed, 20 Feb 2019) | 11 lines

ELF: Fix typo in --build-id option description

Reviewers: ruiu, espindola

Reviewed By: ruiu

Subscribers: emaste, arichardson, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58265
------------------------------------------------------------------------

llvm-svn: 354440

llvm-svn: 354334

llvm-svn: 354331

llvm-svn: 354327

llvm-svn: 354326

llvm-svn: 354321

llvm-svn: 354320

llvm-svn: 354281

------------------------------------------------------------------------
r354034 | rksimon | 2019-02-14 15:45:32 +0100 (Thu, 14 Feb 2019) | 1 line

[X86][AVX] Add PR40730 test case
------------------------------------------------------------------------

------------------------------------------------------------------------
r354117 | rksimon | 2019-02-15 12:39:21 +0100 (Fri, 15 Feb 2019) | 9 lines

[X86][AVX] lowerShuffleAsLanePermuteAndPermute - fully populate the lane shuffle mask (PR40730)

As detailed on PR40730, we are not correctly filling in the lane shuffle mask (D53148/rL344446) - we fill in for the correct src lane but don't add it to the correct mask element, so any reference to the correct element is likely to see an UNDEF mask index.

This allows constant folding to propagate UNDEFs prior to the lane mask being (correctly) lowered to vperm2f128.

This patch fixes the issue by fully populating the lane shuffle mask - this is more than is necessary (if we only filled in the required mask elements we might be able to match other shuffle instructions - broadcasts etc.), but its the most cautious approach as this needs to be cherrypicked into the 8.0.0 release branch.

Differential Revision: https://reviews.llvm.org/D58237
------------------------------------------------------------------------

llvm-svn: 354260

------------------------------------------------------------------------
r353907 | rnk | 2019-02-13 02:39:32 +0100 (Wed, 13 Feb 2019) | 6 lines

[MC] Make symbol version errors non-fatal

We stil don't have a source location, which is pretty lame, but at least
we won't tell the user to file a clang bug report anymore.

Fixes PR40712
------------------------------------------------------------------------

llvm-svn: 354257