Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-02-11T09:36:46+00:00 2020-02-11T09:36:46+00:00 David Blaikie dblaikie@gmail.com 2020-02-06T22:37:23+00:00 urn:sha1:4e6ec0fff658cbe29e70f46491917202baa061c0 Summary: Debug Info Version was changed to use "Max" instead of "Warning" per the original design intent - but this maxes old/new IR unlinkable, since mismatched merge styles are a linking failure. It seems possible/maybe reasonable to actually support the combination of these two flags: Warn, but then use the maximum value rather than the first value/earlier module's value. Reviewers: tejohnson Differential Revision: https://reviews.llvm.org/D74257 (cherry picked from commit ba9cae58bbdd41451ee67773c9d0f90a01756f12) 2019-12-25T00:27:51+00:00 Fangrui Song maskray@google.com 2019-12-25T00:11:33+00:00 urn:sha1:a36ddf0aa9db5c1086e04f56b5f077b761712eb5 2019-12-24T23:57:33+00:00 Fangrui Song maskray@google.com 2019-12-24T23:52:21+00:00 urn:sha1:502a77f125f43ffde57af34d3fd1b900248a91cd 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-01-15T16:18:52+00:00 James Y Knight jyknight@google.com 2019-01-15T16:18:52+00:00 urn:sha1:693d39dd12710a3634e287dfa5d0dd516fbe24d6 compiler identification lines in test-cases. (Doing so only because it's then easier to search for references which are actually important and need fixing.) llvm-svn: 351200 2018-12-14T15:38:15+00:00 Scott Linder scott@scottlinder.com 2018-12-14T15:38:15+00:00 urn:sha1:de6beb02a530a8da6e0525e99b9c1ab24252064e Implement options in clang to enable recording the driver command-line in an ELF section. Implement a new special named metadata, llvm.commandline, to support frontends embedding their command-line options in IR/ASM/ELF. This differs from the GCC implementation in some key ways: * In GCC there is only one command-line possible per compilation-unit, in LLVM it mirrors llvm.ident and multiple are allowed. * In GCC individual options are separated by NULL bytes, in LLVM entire command-lines are separated by NULL bytes. The advantage of the GCC approach is to clearly delineate options in the face of embedded spaces. The advantage of the LLVM approach is to support merging multiple command-lines unambiguously, while handling embedded spaces with escaping. Differential Revision: https://reviews.llvm.org/D54487 Clang Differential Revision: https://reviews.llvm.org/D54489 llvm-svn: 349155 2018-10-09T01:17:27+00:00 David Blaikie dblaikie@gmail.com 2018-10-09T01:17:27+00:00 urn:sha1:40a64c4c08d3c1f4c2cdca657d691c97bf09e580 This might produce hard to read/illegible diagnostics for especially weird/non-trivial module metadata but integers are about all we are using these days, so seems more useful than not. Patch based on work by Kristina Brooks - thanks! Differential Revision: https://reviews.llvm.org/D52952 llvm-svn: 344011 2018-09-24T04:42:14+00:00 Matt Arsenault Matthew.Arsenault@amd.com 2018-09-24T04:42:14+00:00 urn:sha1:9a71e8064581ed8567c8bad52a27fd5ad410e6d8 llvm-svn: 342858 2018-05-09T02:40:45+00:00 Shiva Chen shiva0217@gmail.com 2018-05-09T02:40:45+00:00 urn:sha1:2c864551df3945f50e1780b2f2c880ec358ae715 In order to set breakpoints on labels and list source code around labels, we need collect debug information for labels, i.e., label name, the function label belong, line number in the file, and the address label located. In order to keep these information in LLVM IR and to allow backend to generate debug information correctly. We create a new kind of metadata for labels, DILabel. The format of DILabel is !DILabel(scope: !1, name: "foo", file: !2, line: 3) We hope to keep debug information as much as possible even the code is optimized. So, we create a new kind of intrinsic for label metadata to avoid the metadata is eliminated with basic block. The intrinsic will keep existing if we keep it from optimized out. The format of the intrinsic is llvm.dbg.label(metadata !1) It has only one argument, that is the DILabel metadata. The intrinsic will follow the label immediately. Backend could get the label metadata through the intrinsic's parameter. We also create DIBuilder API for labels to be used by Frontend. Frontend could use createLabel() to allocate DILabel objects, and use insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR. Differential Revision: https://reviews.llvm.org/D45024 Patch by Hsiangkai Wang. llvm-svn: 331841 2018-02-23T23:13:18+00:00 Scott Linder scott@scottlinder.com 2018-02-23T23:13:18+00:00 urn:sha1:c16b975ac8275d0503411b2a4bcb76112c19d046 Add files which I missed in the original check-in llvm-svn: 325973