aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/IRReader
AgeCommit message (Collapse)AuthorFilesLines
2023-01-18[BitcodeReader] Allow reading pointer types from old IRSebastian Neubauer1-8/+9
When opaque pointers are enabled and old IR with typed pointers is read, the BitcodeReader automatically upgrades all typed pointers to opaque pointers. This is a lossy conversion, i.e. when a function argument is a pointer and unused, it’s impossible to reconstruct the original type behind the pointer. There are cases where the type information of pointers is needed. One is reading DXIL, which is bitcode of old LLVM IR and makes a lot of use of pointers in function signatures. We’d like to keep using up-to-date llvm to read in and process DXIL, so in the face of opaque pointers, we need some way to access the type information of pointers from the read bitcode. This patch allows extracting type information by supplying functions to parseBitcodeFile that get called for each function signature or metadata value. The function can access the type information via the reader’s type IDs and the getTypeByID and getContainedTypeID functions. The tests exemplarily shows how type info from pointers can be stored in metadata for use after the BitcodeReader finished. Differential Revision: https://reviews.llvm.org/D127728
2023-01-18Revert "[BitcodeReader] Allow reading pointer types from old IR"Nikita Popov1-9/+8
This reverts commit b56df190b01335506ce30a4559d880da76d1a181. The unit tests are implemented in a way that requires support for writing typed pointer bitcode, which is going away soon. Please rewrite it in a way that not have requirement, e.g. by shipping pre-compiled bitcode, as we do for integration tests.
2023-01-17[BitcodeReader] Allow reading pointer types from old IRSebastian Neubauer1-8/+9
When opaque pointers are enabled and old IR with typed pointers is read, the BitcodeReader automatically upgrades all typed pointers to opaque pointers. This is a lossy conversion, i.e. when a function argument is a pointer and unused, it’s impossible to reconstruct the original type behind the pointer. There are cases where the type information of pointers is needed. One is reading DXIL, which is bitcode of old LLVM IR and makes a lot of use of pointers in function signatures. We’d like to keep using up-to-date llvm to read in and process DXIL, so in the face of opaque pointers, we need some way to access the type information of pointers from the read bitcode. This patch allows extracting type information by supplying functions to parseBitcodeFile that get called for each function signature or metadata value. The function can access the type information via the reader’s type IDs and the getTypeByID and getContainedTypeID functions. The tests exemplarily shows how type info from pointers can be stored in metadata for use after the BitcodeReader finished. Differential Revision: https://reviews.llvm.org/D127728
2022-12-07[IRReader] Convert Optional in DataLayoutCallbackTy to std::optionalKrzysztof Parzyszek1-0/+1
2021-03-25[NFC] Reordering parameters in getFile and getFileOrSTDINAbhina Sreeskantharajan1-3/+1
In future patches I will be setting the IsText parameter frequently so I will refactor the args to be in the following order. I have removed the FileSize parameter because it is never used. ``` static ErrorOr<std::unique_ptr<MemoryBuffer>> getFile(const Twine &Filename, bool IsText = false, bool RequiresNullTerminator = true, bool IsVolatile = false); static ErrorOr<std::unique_ptr<MemoryBuffer>> getFileOrSTDIN(const Twine &Filename, bool IsText = false, bool RequiresNullTerminator = true); static ErrorOr<std::unique_ptr<MB>> getFileAux(const Twine &Filename, uint64_t MapSize, uint64_t Offset, bool IsText, bool RequiresNullTerminator, bool IsVolatile); static ErrorOr<std::unique_ptr<WritableMemoryBuffer>> getFile(const Twine &Filename, bool IsVolatile = false); ``` Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D99182
2021-03-23[NFC] Formatting changesAbhina Sreeskantharajan1-3/+3
This patch addresses some formatting changes from the comments in https://reviews.llvm.org/D97785. Reviewed By: anirudhp Differential Revision: https://reviews.llvm.org/D99072
2021-03-19[SystemZ][z/OS] Distinguish between text and binary files on z/OSAbhina Sreeskantharajan1-1/+3
This patch consists of the initial changes to help distinguish between text and binary content correctly on z/OS. I would like to get feedback from Windows users on setting OF_None for all ToolOutputFiles. This seems to have been done as an optimization to prevent CRLF translation on Windows in the past. Reviewed By: zibi Differential Revision: https://reviews.llvm.org/D97785
2020-12-01static const char *const foo => const char foo[]Fangrui Song1-4/+4
By default, a non-template variable of non-volatile const-qualified type having namespace-scope has internal linkage, so no need for `static`.
2020-11-13llvmbuildectomy - replace llvm-build by plain cmakeserge-sans-paille2-21/+6
No longer rely on an external tool to build the llvm component layout. Instead, leverage the existing `add_llvm_componentlibrary` cmake function and introduce `add_llvm_component_group` to accurately describe component behavior. These function store extra properties in the created targets. These properties are processed once all components are defined to resolve library dependencies and produce the header expected by llvm-config. Differential Revision: https://reviews.llvm.org/D90848
2020-05-14Infer alignment of unmarked loads in IR/bitcode parsing.Eli Friedman1-12/+7
For IR generated by a compiler, this is really simple: you just take the datalayout from the beginning of the file, and apply it to all the IR later in the file. For optimization testcases that don't care about the datalayout, this is also really simple: we just use the default datalayout. The complexity here comes from the fact that some LLVM tools allow overriding the datalayout: some tools have an explicit flag for this, some tools will infer a datalayout based on the code generation target. Supporting this properly required plumbing through a bunch of new machinery: we want to allow overriding the datalayout after the datalayout is parsed from the file, but before we use any information from it. Therefore, IR/bitcode parsing now has a callback to allow tools to compute the datalayout at the appropriate time. Not sure if I covered all the LLVM tools that want to use the callback. (clang? lli? Misc IR manipulation tools like llvm-link?). But this is at least enough for all the LLVM regression tests, and IR without a datalayout is not something frontends should generate. This change had some sort of weird effects for certain CodeGen regression tests: if the datalayout is overridden with a datalayout with a different program or stack address space, we now parse IR based on the overridden datalayout, instead of the one written in the file (or the default one, if none is specified). This broke a few AVR tests, and one AMDGPU test. Outside the CodeGen tests I mentioned, the test changes are all just fixing CHECK lines and moving around datalayout lines in weird places. Differential Revision: https://reviews.llvm.org/D78403
2019-11-21[cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard1-1/+1
Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
2019-02-11[IRReader] Expose getLazyIRModuleScott Linder1-3/+3
Currently there is no way to lazy-load an in-memory IR module without first writing it to disk. This patch just exposes the existing implementation of getLazyIRModule. This is effectively a revert of rL212364 Differential Revision: https://reviews.llvm.org/D56203 llvm-svn: 353755
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2-8/+6
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-01-30LLParser: add an argument for overriding data layout and do not check alloca ↵Yaxun Liu1-4/+9
addr space Sometimes users do not specify data layout in LLVM assembly and let llc set the data layout by target triple after loading the LLVM assembly. Currently the parser checks alloca address space no matter whether the LLVM assembly contains data layout definition, which causes false alarm since the default data layout does not contain the correct alloca address space. The parser also calls verifier to check debug info and updating invalid debug info. Currently there is no way to let the verifier to check debug info only. If the verifier finds non-debug-info issues the parser will fail. For llc, the fix is to remove the check of alloca addr space in the parser and disable updating debug info, and defer the updating of debug info and verification to be after setting data layout of the IR by target. For other llvm tools, since they do not override data layout by target but instead can override data layout by a command line option, an argument for overriding data layout is added to the parser. In cases where data layout overriding is necessary for the parser, the data layout can be provided by command line. Differential Revision: https://reviews.llvm.org/D41832 llvm-svn: 323826
2017-12-13Remove redundant includes from various places.Michael Zolotukhin1-1/+0
llvm-svn: 320629
2017-10-02Move the stripping of invalid debug info from the Verifier to AutoUpgrade.Adrian Prantl1-4/+7
This came out of a recent discussion on llvm-dev (https://reviews.llvm.org/D38042). Currently the Verifier will strip the debug info metadata from a module if it finds the dbeug info to be malformed. This feature is very valuable since it allows us to improve the Verifier by making it stricter without breaking bcompatibility, but arguable the Verifier pass should not be modifying the IR. This patch moves the stripping of broken debug info into AutoUpgrade (UpgradeDebugInfo to be precise), which is a much better location for this since the stripping of malformed (i.e., produced by older, buggy versions of Clang) is a (harsh) form of AutoUpgrade. This change is mostly NFC in nature, the one big difference is the behavior when LLVM module passes are introducing malformed debug info. Prior to this patch, a NoAsserts build would have printed a warning and stripped the debug info, after this patch the Verifier will report a fatal error. I believe this behavior is actually more desirable anyway. Differential Revision: https://reviews.llvm.org/D38184 llvm-svn: 314699
2016-11-18Timer: Track name and description.Matthias Braun1-3/+6
The previously used "names" are rather descriptions (they use multiple words and contain spaces), use short programming language identifier like strings for the "names" which should be used when exporting to machine parseable formats. Also removed a unused TimerGroup from Hexxagon. Differential Revision: https://reviews.llvm.org/D25583 llvm-svn: 287369
2016-11-13Bitcode: Change module reader functions to return an llvm::Expected.Peter Collingbourne1-8/+12
Differential Revision: https://reviews.llvm.org/D26562 llvm-svn: 286752
2016-11-11Split Bitcode/ReaderWriter.h into separate reader and writer headersTeresa Johnson1-1/+1
Summary: Split ReaderWriter.h which contains the APIs into both the BitReader and BitWriter libraries into BitcodeReader.h and BitcodeWriter.h. This is to address Chandler's concern about sharing the same API header between multiple libraries (BitReader and BitWriter). That concern is why we create a single bitcode library in our downstream build of clang, which led to r286297 being reverted as it added a dependency that created a cycle only when there is a single bitcode library (not two as in upstream). Reviewers: mehdi_amini Subscribers: dlj, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D26502 llvm-svn: 286566
2016-11-08IR, Bitcode: Change bitcode reader to no longer own its memory buffer.Peter Collingbourne1-1/+1
Unique ownership is just one possible ownership pattern for the memory buffer underlying the bitcode reader. In practice, as this patch shows, ownership can often reside at a higher level. With the upcoming change to allow multiple modules in a single bitcode file, it will no longer be appropriate for modules to generally have unique ownership of their memory buffer. The C API exposes the ownership relation via the LLVMGetBitcodeModuleInContext and LLVMGetBitcodeModuleInContext2 functions, so we still need some way for the module to own the memory buffer. This patch does so by adding an owned memory buffer field to Module, and using it in a few other places where it is convenient. Differential Revision: https://reviews.llvm.org/D26384 llvm-svn: 286214
2016-01-26Remove autoconf supportChris Bieneman1-14/+0
Summary: This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html "I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened." - Obi Wan Kenobi Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D16471 llvm-svn: 258861
2015-12-17[ThinLTO] Metadata linking for imported functionsTeresa Johnson1-5/+7
Summary: Second patch split out from http://reviews.llvm.org/D14752. Maps metadata as a post-pass from each module when importing complete, suturing up final metadata to the temporary metadata left on the imported instructions. This entails saving the mapping from bitcode value id to temporary metadata in the importing pass, and from bitcode value id to final metadata during the metadata linking postpass. Depends on D14825. Reviewers: dexonsmith, joker.eph Subscribers: davidxl, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D14838 llvm-svn: 255909
2015-06-16Return a unique_ptr from getLazyBitcodeModule and parseBitcodeFile. NFC.Rafael Espindola1-4/+5
llvm-svn: 239858
2015-06-16modules: Add explicit dependency on intrinsics_genDuncan P. N. Exon Smith1-0/+3
`LLVM_ENABLE_MODULES` builds sometimes fail because `Intrinsics.td` needs to regenerate `Instrinsics.h` before anyone can include anything from the LLVM_IR module. Represent the dependency explicitly to prevent that. llvm-svn: 239796
2015-02-11Use ADDITIONAL_HEADER_DIRS in all LLVM CMake projects.Zachary Turner1-0/+3
This allows IDEs to recognize the entire set of header files for each of the core LLVM projects. Differential Revision: http://reviews.llvm.org/D7526 Reviewed By: Chris Bieneman llvm-svn: 228798
2014-11-06Remove unused variable. NFC.Rafael Espindola1-1/+0
llvm-svn: 221497
2014-09-03Pass a && to getLazyBitcodeModule.Rafael Espindola1-1/+2
This forces callers to use std::move when calling it. It is somewhat odd to have code with std::move that doesn't always move, but it is also odd to have code without std::move that sometimes moves. llvm-svn: 217049
2014-08-26Pass a std::unique_ptr<MemoryBuffer>& to getLazyBitcodeModule.Rafael Espindola1-3/+1
By taking a reference we can do the ownership transfer in one place instead of expecting every caller to do it. llvm-svn: 216492
2014-08-26Pass a MemoryBufferRef when we can avoid taking ownership.Rafael Espindola1-10/+9
The attached patch simplifies a few interfaces that don't need to take ownership of a buffer. For example, both parseAssembly and parseBitcodeFile will parse the entire buffer before returning. There is no need to take ownership. Using a MemoryBufferRef makes it obvious in the type signature that there is no ownership transfer. llvm-svn: 216488
2014-08-26Return a std::unique_ptr from the IRReader.h functions. NFC.Rafael Espindola1-16/+15
llvm-svn: 216466
2014-08-19Modernize the .ll parsing interface.Rafael Espindola1-7/+8
* Use StringRef instead of std::string& * Return a std::unique_ptr<Module> instead of taking an optional module to write to (was not really used). * Use current comment style. * Use current naming convention. llvm-svn: 215989
2014-08-17Pass a std::uinque_ptr to ParseAssembly to make the ownership explicit. NFC.Rafael Espindola1-3/+3
llvm-svn: 215852
2014-08-17getLazyIRModule always takes ownership. Make that explicit.Rafael Espindola1-10/+9
llvm-svn: 215851
2014-07-06Update the MemoryBuffer API to use ErrorOr.Rafael Espindola1-8/+10
llvm-svn: 212405
2014-07-05Make a helper function static. No functionality change.Rafael Espindola1-3/+2
llvm-svn: 212364
2014-06-27IRReader: don't mark MemoryBuffers constAlp Toker1-1/+1
llvm-svn: 211883
2014-06-27Propagate const-correctness into parseBitcodeFile()Alp Toker1-2/+1
llvm-svn: 211864
2014-06-27ParseIR: don't take ownership of the MemoryBufferAlp Toker1-7/+10
clang was needlessly duplicating whole memory buffer contents in an attempt to satisfy unclear ownership semantics. Let's just hide internal LLVM quirks and present a simple non-owning interface. The public C API preserves previous behaviour for stability. llvm-svn: 211861
2014-06-26Revert "Introduce a string_ostream string builder facilty"Alp Toker1-3/+6
Temporarily back out commits r211749, r211752 and r211754. llvm-svn: 211814
2014-06-26MSVC build fix following r211749Alp Toker1-1/+2
Avoid strndup() llvm-svn: 211752
2014-06-26Introduce a string_ostream string builder faciltyAlp Toker1-6/+2
string_ostream is a safe and efficient string builder that combines opaque stack storage with a built-in ostream interface. small_string_ostream<bytes> additionally permits an explicit stack storage size other than the default 128 bytes to be provided. Beyond that, storage is transferred to the heap. This convenient class can be used in most places an std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair would previously have been used, in order to guarantee consistent access without byte truncation. The patch also converts much of LLVM to use the new facility. These changes include several probable bug fixes for truncated output, a programming error that's no longer possible with the new interface. llvm-svn: 211749
2014-06-13Remove 'using std::errro_code' from lib.Rafael Espindola1-5/+4
llvm-svn: 210871
2014-06-12Don't use 'using std::error_code' in include/llvm.Rafael Espindola1-0/+1
This should make sure that most new uses use the std prefix. llvm-svn: 210835
2014-06-12Remove system_error.h.Rafael Espindola1-1/+1
This is a minimal change to remove the header. I will remove the occurrences of "using std::error_code" in a followup patch. llvm-svn: 210803
2014-04-15[C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper1-7/+7
instead of comparing to nullptr. llvm-svn: 206252
2014-03-06Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles1-3/+2
This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
2014-03-05[C++11] Replace OwningPtr::take() with OwningPtr::release().Ahmed Charles1-2/+2
llvm-svn: 202957
2014-01-15Make parseBitcodeFile return an ErrorOr<Module *>.Rafael Espindola1-5/+7
llvm-svn: 199279
2014-01-13Update getLazyBitcodeModule to use ErrorOr for error handling.Rafael Espindola1-4/+5
llvm-svn: 199125
2014-01-07Move the LLVM IR asm writer header files into the IR directory, as theyChandler Carruth1-1/+1
are part of the core IR library in order to support dumping and other basic functionality. Rename the 'Assembly' include directory to 'AsmParser' to match the library name and the only functionality left their -- printing has been in the core IR library for quite some time. Update all of the #includes to match. All of this started because I wanted to have the layering in good shape before I started adding support for printing LLVM IR using the new pass infrastructure, and commandline support for the new pass infrastructure. llvm-svn: 198688
generated by cgit v1.1 at 2024-09-07 15:58:54 +0000