Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2019-07-14T14:06:25+00:00 2019-07-14T14:06:25+00:00 Florian Hahn flo@fhahn.com 2019-07-14T14:06:25+00:00 urn:sha1:19d3fdb08b722a4a66b21b3e08d2008c95f968e8 This recommits r365750 (git commit 8b222ecf2769ee133691f208f6166ce118c4a164) Original message: Currently invalid bitcode files can cause a crash, when OpNum exceeds the number of elements in Record, like in the attached bitcode file. The test case was generated by clusterfuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15698 Reviewers: t.p.northover, thegameg, jfb Reviewed By: jfb Differential Revision: https://reviews.llvm.org/D64507 llvm-svn: 365750jkkkk llvm-svn: 366018 2019-07-11T10:53:40+00:00 Florian Hahn flo@fhahn.com 2019-07-11T10:53:40+00:00 urn:sha1:3b9994615f484d028ab476cf31bf6e62558364e8 This reverts r365750 (git commit 8b222ecf2769ee133691f208f6166ce118c4a164) llvm-dis runs out of memory while opening invalid-fcmp-opnum.bc on llvm-hexagon-elf, probably because the bitcode file contains other suspicious values. http://lab.llvm.org:8011/builders/llvm-hexagon-elf/builds/21949 llvm-svn: 365757 2019-07-11T09:57:00+00:00 Florian Hahn flo@fhahn.com 2019-07-11T09:57:00+00:00 urn:sha1:8b222ecf2769ee133691f208f6166ce118c4a164 Currently invalid bitcode files can cause a crash, when OpNum exceeds the number of elements in Record, like in the attached bitcode file. The test case was generated by clusterfuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15698 Reviewers: t.p.northover, thegameg, jfb Reviewed By: jfb Differential Revision: https://reviews.llvm.org/D64507 llvm-svn: 365750 2019-05-30T18:48:23+00:00 Tim Northover tnorthover@apple.com 2019-05-30T18:48:23+00:00 urn:sha1:b7141207a483d39b99c2b4da4eb3bb591eca9e1a When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128 2019-05-29T20:46:38+00:00 Tim Northover tnorthover@apple.com 2019-05-29T20:46:38+00:00 urn:sha1:71ee3d02372af7361eda0b59163cf92653ac2bbb The IRLinker doesn't delve into the new byval attribute when mapping types, and this breaks LTO. llvm-svn: 362029 2019-05-29T19:12:48+00:00 Tim Northover tnorthover@apple.com 2019-05-29T19:12:48+00:00 urn:sha1:6e07f16fae605c42014aa4f1f2babf3e7767c95c When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362012 2019-04-17T17:38:09+00:00 Steven Wu stevenwu@apple.com 2019-04-17T17:38:09+00:00 urn:sha1:05a358cdcd55d1ee0a0d92383aa49489479c6362 Summary: Reapply r357931 with fixes to ThinLTO testcases and llvm-lto tool. ThinLTOCodeGenerator currently does not preserve llvm.used symbols and it can internalize them. In order to pass the necessary information to the legacy ThinLTOCodeGenerator, the input to the code generator is rewritten to be based on lto::InputFile. Now ThinLTO using the legacy LTO API will requires data layout in Module. "internalize" thinlto action in llvm-lto is updated to run both "promote" and "internalize" with the same configuration as ThinLTOCodeGenerator. The old "promote" + "internalize" option does not produce the same output as ThinLTOCodeGenerator. This fixes: PR41236 rdar://problem/49293439 Reviewers: tejohnson, pcc, kromanova, dexonsmith Reviewed By: tejohnson Subscribers: ormris, bd1976llvm, mehdi_amini, inglorion, eraman, hiraditya, jkorous, dexonsmith, arphaman, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60421 llvm-svn: 358601 2018-09-20T18:59:33+00:00 Vedant Kumar vsk@apple.com 2018-09-20T18:59:33+00:00 urn:sha1:386ad01c7b6d83beb95267116af295471e36d426 r342631 expanded bitc::METADATA_LOCATION by one element. The bitcode metadata loader was changed in a backwards-incompatible way, leading to crashes when disassembling old bitcode: assertion: empty() && "PlaceholderQueue hasn't been flushed before being destroyed" Assertion failed: (empty() && "PlaceholderQueue hasn't been flushed before being destroyed") This commit teaches the metadata loader to assume that the newly-added IsImplicitCode bit is 'false' when not present in old bitcode. I've added a bitcode compat regression test. rdar://44645820 llvm-svn: 342678 2018-07-09T16:52:05+00:00 Steven Wu stevenwu@apple.com 2018-07-09T16:52:05+00:00 urn:sha1:e1f7c5f8c72f77f5c25aa501a974e36b00f949a7 Summary: To allow bitcode built by old compiler to pass the current verifer, BitcodeReader needs to auto infer the correct runtime preemption from linkage and visibility for GlobalValues. Since llvm-6.0 bitcode already contains the new field but can be incorrect in some cases, the attribute needs to be recomputed all the time in BitcodeReader. This will make all the GVs has dso_local marked correctly if read from bitcode, and it should still allow the verifier to catch mistakes in optimization passes. This should fix PR38009. Reviewers: sfertile, vsk Reviewed By: vsk Subscribers: dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D49039 llvm-svn: 336560 2017-08-03T17:11:41+00:00 Dehao Chen dehao@google.com 2017-08-03T17:11:41+00:00 urn:sha1:f58df39529060196b8ead812521b3a98ccd8abc3 Summary: For SamplePGO, we already record the callsite count in the call instruction itself. So we do not want to use BFI to get profile count as it is less accurate. Reviewers: tejohnson, davidxl, eraman Reviewed By: eraman Subscribers: sanjoy, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D36025 llvm-svn: 309964