- Mar 07, 2019
-
-
Robin Randhawa authored
Untested
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Feb 26, 2019
-
-
Alex Crichton authored
Another upstream merge + build system fix
-
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.
-
Alex Crichton authored
-
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
-
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
-
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
-
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
-
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
-
Hans Wennborg authored
llvm-svn: 354855
-
- Feb 25, 2019
-
-
Anastasia Stulova authored
Differential Revision: https://reviews.llvm.org/D58504 llvm-svn: 354799
-
Hans Wennborg authored
llvm-svn: 354794
-
Alex Crichton authored
-
Alex Crichton authored
Another merge of the upstream 8.x branch
-
Alex Crichton authored
-
- Feb 22, 2019
-
-
Hans Wennborg authored
llvm-svn: 354660
-
Hans Wennborg authored
llvm-svn: 354659
-
- Feb 21, 2019
-
-
Hans Wennborg authored
llvm-svn: 354583
-
Hans Wennborg authored
llvm-svn: 354582
-
Hans Wennborg authored
------------------------------------------------------------------------ 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
-
Hans Wennborg authored
llvm-svn: 354554
-
- Feb 20, 2019
-
-
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
-
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
-
Hans Wennborg authored
llvm-svn: 354458
-
Hans Wennborg authored
llvm-svn: 354457
-