summaryrefslogtreecommitdiffstats
path: root/llvm/include
Commit message (Collapse)AuthorAgeFilesLines
...
* Re-apply "[DebugInfo] Check size of variable in ConvertDebugDeclareToDebugValue"Bjorn Pettersson2018-06-151-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is r334704 (which was reverted in r334732) with a fix for types like x86_fp80. We need to use getTypeAllocSizeInBits and not getTypeStoreSizeInBits to avoid dropping debug info for such types. Original commit msg: > Summary: > Do not convert a DbgDeclare to DbgValue if the store > instruction only refer to a fragment of the variable > described by the DbgDeclare. > > Problem was seen when for example having an alloca for an > array or struct, and there were stores to individual elements. > In the past we inserted a DbgValue intrinsics for each store, > just as if the store wrote the whole variable. > > When handling store instructions we insert a DbgValue that > indicates that the variable is "undefined", as we do not know > which part of the variable that is updated by the store. > > When ConvertDebugDeclareToDebugValue is used with a load/phi > instruction we assert that the referenced value is large enough > to cover the whole variable. Afaict this should be true for all > scenarios where those methods are used on trunk. If the assert > blows in the future I guess we could simply skip to insert a > dbg.value instruction. > > In the future I think we should examine which part of the variable > that is accessed, and add a DbgValue instrinsic with an appropriate > DW_OP_LLVM_fragment expression. > > Reviewers: dblaikie, aprantl, rnk > > Reviewed By: aprantl > > Subscribers: JDevlieghere, llvm-commits > > Tags: #debug-info > > Differential Revision: https://reviews.llvm.org/D48024 llvm-svn: 334830
* [MC] Move bundling and MCSubtargetInfo to MCEncodedFragment [NFC]Peter Smith2018-06-152-53/+52
| | | | | | | | | | | | | | Instruction bundling is only supported on descendants of the MCEncodedFragment type. By moving the bundling functionality and MCSubtargetInfo to this class it makes it easier to set and extract the MCSubtargetInfo when it is necessary. This is a refactoring change that will make it easier to pass the MCSubtargetInfo through to writeNops when nop padding is required. Differential Revision: https://reviews.llvm.org/D45959 llvm-svn: 334814
* [MSSA] Print more optimization informationGeorge Burgess IV2018-06-141-0/+3
| | | | | | | | | | | | | | In particular, when asked to print a MemoryAccess, we'll now print where defs are optimized to, and we'll print optimized access types. This patch also introduces an operator<< to make printing AliasResults easier. Patch by Juneyoung Lee! Differential Revision: https://reviews.llvm.org/D47860 llvm-svn: 334760
* [X86] Lowering Mask Scalar intrinsics to native IR (LLVM part)Tomasz Krupa2018-06-141-2/+2
| | | | | | | | | | | | | | | Summary: Complementary patch to lowering add, sub, mul and div mask scalar intrinsics in Clang. Reviewers: craig.topper, sroland, spatel, RKSimon Reviewed by: craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D47978 llvm-svn: 334740
* Revert "[MC] Factor MCObjectStreamer::addFragmentAtoms out of MachO streamer."Sam Clegg2018-06-141-2/+0
| | | | | | | | | This reverts rL331412. We didn't up using fragment atoms in the wasm object writer after all. Differential Revision: https://reviews.llvm.org/D48173 llvm-svn: 334734
* Revert rL334704: "[DebugInfo] Check size of variable in ↵Bjorn Pettersson2018-06-141-4/+0
| | | | | | | | | | ConvertDebugDeclareToDebugValue" This reverts commit r334704. Buildbots detected an assertion in "test tsan in debug compiler-rt build". llvm-svn: 334732
* [ORC] Add a WaitUntilReady argument to blockingLookup.Lang Hames2018-06-141-1/+1
| | | | | | | | | | | If WaitUntilReady is set to true then blockingLookup will return once all requested symbols are ready. If WaitUntilReady is set to false then blockingLookup will return as soon as all requested symbols have been resolved. In the latter case, if any error occurs in finalizing the symbols it will be reported to the ExecutionSession, rather than returned by blockingLookup. llvm-svn: 334722
* [DWARFv5] Tolerate files not all having an MD5 checksum.Paul Robinson2018-06-142-3/+31
| | | | | | | | | | | | | | | | | | In some cases, for example when compiling a preprocessed file, the front-end is not able to provide an MD5 checksum for all files. When that happens, omit the MD5 checksums from the final DWARF, because DWARF doesn't have a way to indicate that some but not all files have a checksum. When assembling a .s file, and some but not all .file directives provide an MD5 checksum, issue a warning and don't emit MD5 into the DWARF. Fixes PR37623. Differential Revision: https://reviews.llvm.org/D48135 llvm-svn: 334710
* [DebugInfo] Check size of variable in ConvertDebugDeclareToDebugValueBjorn Pettersson2018-06-141-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Do not convert a DbgDeclare to DbgValue if the store instruction only refer to a fragment of the variable described by the DbgDeclare. Problem was seen when for example having an alloca for an array or struct, and there were stores to individual elements. In the past we inserted a DbgValue intrinsics for each store, just as if the store wrote the whole variable. When handling store instructions we insert a DbgValue that indicates that the variable is "undefined", as we do not know which part of the variable that is updated by the store. When ConvertDebugDeclareToDebugValue is used with a load/phi instruction we assert that the referenced value is large enough to cover the whole variable. Afaict this should be true for all scenarios where those methods are used on trunk. If the assert blows in the future I guess we could simply skip to insert a dbg.value instruction. In the future I think we should examine which part of the variable that is accessed, and add a DbgValue instrinsic with an appropriate DW_OP_LLVM_fragment expression. Reviewers: dblaikie, aprantl, rnk Reviewed By: aprantl Subscribers: JDevlieghere, llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D48024 llvm-svn: 334704
* Revert "Enable ThreadPool to queue tasks that return values."Zachary Turner2018-06-131-44/+7
| | | | | | | | This is failing to compile when LLVM_ENABLE_THREADS is false, and the fix is not immediately obvious, so reverting while I look into it. llvm-svn: 334658
* Update comments of CheckedArithmetic API based on Philip Reames feedback.George Karpenkov2018-06-131-11/+17
| | | | llvm-svn: 334655
* Add missing #include.Zachary Turner2018-06-131-0/+1
| | | | llvm-svn: 334644
* Enable ThreadPool to support tasks that return values.Zachary Turner2018-06-131-7/+43
| | | | | | | | | | | | | | | | | | | | | Previously ThreadPool could only queue async "jobs", i.e. work that was done for its side effects and not for its result. It's useful occasionally to queue async work that returns a value. From an API perspective, this is very intuitive. The previous API just returned a shared_future<void>, so all we need to do is make it return a shared_future<T>, where T is the type of value that the operation returns. Making this work required a little magic, but ultimately it's not too bad. Instead of keeping a shared queue<packaged_task<void()>> we just keep a shared queue<unique_ptr<TaskBase>>, where TaskBase is a class with a pure virtual execute() method, then have a templated derived class that stores a packaged_task<T()>. Everything else works out pretty cleanly. Differential Revision: https://reviews.llvm.org/D48115 llvm-svn: 334643
* Add checkMulAdd helper function to CheckedArithmeticGeorge Karpenkov2018-06-131-0/+20
| | | | | | | | | | Multiplication followed by addition (https://en.wikipedia.org/wiki/Multiply–accumulate_operation) is a sufficiently common use-case to warrant a separate helper. Differential Revision: https://reviews.llvm.org/D48138 llvm-svn: 334635
* Change checked arithmetic functions API to return OptionalGeorge Karpenkov2018-06-131-33/+28
| | | | | | | | | | Returning optional is much safer. The previous API had potential to cause use of undefined variables, if the value passed by pointer was accidentally read afterwards. Differential Revision: https://reviews.llvm.org/D48137 llvm-svn: 334634
* LTO: Keep file handles open for memory mapped files.Peter Collingbourne2018-06-132-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Windows we've observed that if you open a file, write to it, map it into memory and close the file handle, the contents of the memory mapping can sometimes be incorrect. That was what we did when adding an entry to the ThinLTO cache using the TempFile and MemoryBuffer classes, and it was causing intermittent build failures on Chromium's ThinLTO bots on Windows. More details are in the associated Chromium bug (crbug.com/786127). We can prevent this from happening by keeping a handle to the file open while the mapping is active. So this patch changes the mapped_file_region class to duplicate the file handle when mapping the file and close it upon unmapping it. One gotcha is that the file handle that we keep open must not have been created with FILE_FLAG_DELETE_ON_CLOSE, as otherwise the operating system will prevent other processes from opening the file. We can achieve this by avoiding the use of FILE_FLAG_DELETE_ON_CLOSE altogether. Instead, we use SetFileInformationByHandle with FileDispositionInfo to manage the delete-on-close bit. This lets us remove the hack that we used to use to clear the delete-on-close bit on a file opened with FILE_FLAG_DELETE_ON_CLOSE. A downside of using SetFileInformationByHandle/FileDispositionInfo as opposed to FILE_FLAG_DELETE_ON_CLOSE is that it prevents us from using CreateFile to open the file while the flag is set, even within the same process. This doesn't seem to matter for almost every client of TempFile, except for LockFileManager, which calls sys::fs::create_link to create a hard link from the lock file, and in the process of doing so tries to open the file. To prevent this change from breaking LockFileManager I changed it to stop using TempFile by effectively reverting r318550. Differential Revision: https://reviews.llvm.org/D48051 llvm-svn: 334630
* IR: fix documentation markupSaleem Abdulrasool2018-06-131-2/+2
| | | | | | Use `\brief` instead of `\Brief`. NFC. llvm-svn: 334627
* [TableGen] Emit a fatal error on inconsistencies in resource units vs cycles.Clement Courbet2018-06-131-4/+3
| | | | | | | | | | | | | | | | | | | | | Summary: For targets I'm not familiar with, I've automatically made the "default to 1 for each resource" behaviour explicit in the td files. For more obvious cases, I've ventured a fix. Some notes: - Exynos is especially fishy. - AArch64SchedThunderX2T99.td had some truncated entries. If I understand correctly, the person who wrote that interpreted the ResourceCycle as a range. I made the decision to use the upper/lower bound for consistency with the 'Latency' value. I'm sure there is a better choice. - The change to X86ScheduleBtVer2.td is an NFC, it just makes values more explicit. Also see PR37310. Reviewers: RKSimon, craig.topper, javed.absar Subscribers: kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D46356 llvm-svn: 334586
* [DWARF/AccelTable] Remove getDIESectionOffset for DWARF v5 entriesPavel Labath2018-06-133-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This method was not correct for entries in DWO files as it assumed it could just add up the CU and DIE offsets to get the absolute DIE offset. This is not correct for the DWO files, as here the CU offset will reference the skeleton unit, whereas the DIE offset will be the offset in the full unit in the DWO file. Unfortunately, this means that we are not able to determine the absolute DIE offset using the information in the .debug_names section alone, which means we have to offload some of this work to the users of this class. To demonstrate how this can be done, I've added/fixed the ability to lookup entries using accelerator tables in DWO files in llvm-dwarfdump. To make this happen, I've needed to make two extra changes in other classes: - made the DWARFContext method to lookup a CU based on the section offset public. I've needed this functionality to lookup a CU, and this seems like a useful thing in general. - made DWARFUnit::getDWOId call extractDIEsIfNeeded. Before this, the DWOId was filled in only if the root DIE happened to be parsed before we called the accessor. Since the lazy parsing is supposed to happen under the hood, calling extractDIEsIfNeeded seems appropriate. Reviewers: JDevlieghere, aprantl, dblaikie Subscribers: mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D48009 llvm-svn: 334578
* [X86] Remove masking from avx512vbmi2 concat and shift by immediate ↵Craig Topper2018-06-131-72/+54
| | | | | | intrinsics. Use select in IR instead. llvm-svn: 334576
* Added missing include to AMDHSAKernelDescriptor.hRaphael Isemann2018-06-121-0/+1
| | | | | | | We use size_t in this header, so we also need to include cstddef to make it compile. Fixes the module builds. llvm-svn: 334555
* [ORC] Add a fallback definition generator for VSOs.Lang Hames2018-06-121-0/+19
| | | | | | | | | | | | If a VSO has a fallback definition generator attached it will be called during lookup (and lookupFlags) for any unresolved symbols. The definition generator can add new definitions to the VSO for any unresolved symbol. This allows VSOs to generate new definitions on demand. The immediate use case for this code is supporting VSOs that can import definitions found via dlsym on demand. llvm-svn: 334538
* [ORC] Refactor blocking lookup logic into the blockingLookup function, andLang Hames2018-06-121-0/+9
| | | | | | | implement existing blocking lookups (the lookup function) and JITSymbolResolverAdapter on top of that. llvm-svn: 334537
* [MS][ARM64] Hoist __ImageBase handling into TargetLoweringObjectFileCOFFReid Kleckner2018-06-121-0/+10
| | | | | | | | | | | | All COFF targets should use @IMGREL32 relocations for symbol differences against __ImageBase. Do the same for getSectionForConstant, so that immediates lowered to globals get merged across TUs. Patch by Chris January Differential Revision: https://reviews.llvm.org/D47783 llvm-svn: 334523
* [MIR][MachineCSE] Implementing proper MachineInstr::getNumExplicitDefs()Roman Tereshin2018-06-121-10/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently, MachineInstr class definition as well as pretty much all of the machine passes assume that the only kind of MachineInstr's operands that is variadic for variadic opcodes is explicit non-definitions. In particular, this assumption is made by MachineInstr::defs(), uses(), and explicit_uses() methods, as well as by MachineCSE pass. The assumption is incorrect judging from at least TableGen backend implementation, that recognizes variable_ops in OutOperandList, and the very existence of G_UNMERGE_VALUES generic opcode, or ARM load multiple instructions, all of which have variadic defs. In particular, MachineCSE pass breaks MIR with CSE'able G_UNMERGE_VALUES instructions in it. This commit implements MachineInstr::getNumExplicitDefs() similar to pre-existing MachineInstr::getNumExplicitOperands(), fixes MachineInstr::defs(), uses(), and explicit_uses(), and fixes MachineCSE pass. As the issue addressed seems to affect only machine passes that could be ran mid-GlobalISel pipeline at the moment, the other passes aren't fixed by this commit, like MachineLICM: that could be done on per-pass basis when (if ever) they get adopted for GlobalISel. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D45640 llvm-svn: 334520
* AMDHSA: Code object v3 updatesKonstantin Zhuravlyov2018-06-122-139/+187
| | | | | | | | | | | | | | | - Do not emit following assembler directives: - .hsa_code_object_version - .hsa_code_object_isa - .amd_amdgpu_isa - .amd_amdgpu_hsa_metadata - .amd_amdgpu_pal_metadata - Do not emit .note entries - Cleanup and bring in sync kernel descriptor header file - Emit kernel descriptor into .rodata with appropriate relocations and alignments llvm-svn: 334519
* Refactor ExecuteAndWait to take StringRefs.Zachary Turner2018-06-122-7/+18
| | | | | | | | | | | | | | | | | | | This simplifies some code which had StringRefs to begin with, and makes other code more complicated which had const char* to begin with. In the end, I think this makes for a more idiomatic and platform agnostic API. Not all platforms launch process with null terminated c-string arrays for the environment pointer and argv, but the api was designed that way because it allowed easy pass-through for posix-based platforms. There's a little additional overhead now since on posix based platforms we'll be takign StringRefs which were constructed from null terminated strings and then copying them to null terminate them again, but from a readability and usability standpoint of the API user, I think this API signature is strictly better. llvm-svn: 334518
* [CostModel] Replace ShuffleKind::SK_Alternate with ShuffleKind::SK_Select ↵Simon Pilgrim2018-06-122-2/+4
| | | | | | | | | | | | | | | | | | (PR33744) As discussed on PR33744, this patch relaxes ShuffleKind::SK_Alternate which requires shuffle masks to only match an alternating pattern from its 2 sources: e.g. v4f32: <0,5,2,7> or <4,1,6,3> This seems far too restrictive as most SIMD hardware which will implement it using a general blend/bit-select instruction, so replaces it with SK_Select, permitting elements from either source as long as they are inline: e.g. v4f32: <0,5,2,7>, <4,1,6,3>, <0,1,6,7>, <4,1,2,3> etc. This initial patch just updates the name and cost model shuffle mask analysis, later patch reviews will update SLP to better utilise this - it still limits itself to SK_Alternate style patterns. Differential Revision: https://reviews.llvm.org/D47985 llvm-svn: 334513
* [DWARFv5] llvm-mc -dwarf-version does not imply -g.Paul Robinson2018-06-121-2/+2
| | | | | | | | | | | | | Don't provide the assembler source as the "root file" unless the user asked to have debug info for the assembler source (with -g). If the source doesn't provide an explicit ".file 0" then (a) use the compilation directory as directory #0, and (b) use the file #1 info for file #0 also. Differential Revision: https://reviews.llvm.org/D48055 llvm-svn: 334512
* [NFC] Change sample profile format enum name SPF_Raw_Binary to SPF_Binary.Wei Mi2018-06-122-3/+3
| | | | | | | Some out-of-tree targets depend on the enum name SPF_Binary. Keep the name can avoid unnecessary churn to those targets. llvm-svn: 334476
* Fix a buildbot error reported by sanitizer-x86_64-linux-fast:Wei Mi2018-06-111-0/+2
| | | | | | Function::getGUID may complain if its input is an empty StringRef. llvm-svn: 334455
* Fix a warning reported by clang but not by gcc.Wei Mi2018-06-111-1/+1
| | | | llvm-svn: 334449
* [SampleFDO] Add a new compact binary format for sample profile.Wei Mi2018-06-113-29/+110
| | | | | | | | | | | | | | Name table occupies a big chunk of size in current binary format sample profile. In order to reduce its size, the patch changes the sample writer/reader to save/restore MD5Hash of names in the name table. Sample annotation phase will also use MD5Hash of name to query samples accordingly. Experiment shows compact binary format can reduce the size of sample profile by 2/3 compared with binary format generally. Differential Revision: https://reviews.llvm.org/D47955 llvm-svn: 334447
* AMDGPU: Add 64-bit relative variant kindKonstantin Zhuravlyov2018-06-111-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D47601 llvm-svn: 334443
* Move VersionTuple from clang/Basic to llvm/SupportPavel Labath2018-06-111-0/+154
| | | | | | | | | | | | | | | | | | | | | | | Summary: This kind of functionality is useful to other project apart from clang. LLDB works with version numbers a lot, but it does not have a convenient abstraction for this. Moving this class to a lower level library allows it to be freely used within LLDB. Since this class is used in a lot of places in clang, and it used to be in the clang namespace, it seemed appropriate to add it to the list of adopted classes in LLVM.h to avoid prefixing all uses with "llvm::". Also, I didn't find any tests specific for this class, so I wrote a couple of quick ones for the more interesting bits of functionality. Reviewers: zturner, erik.pilkington Subscribers: mgorny, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D47887 llvm-svn: 334399
* [X86] Remove masking from dbpsadbw intrinsics, use select in IR instead.Craig Topper2018-06-111-12/+9
| | | | llvm-svn: 334384
* [X86] Remove and autoupgrade the expandload and compressstore intrinsics.Craig Topper2018-06-111-114/+0
| | | | | | We use the target independent intrinsics now. llvm-svn: 334381
* Attempt 3: Resubmit "[Support] Expose flattenWindowsCommandLine."Zachary Turner2018-06-101-0/+13
| | | | | | | | | | | | | | | | | | I took some liberties and quoted fewer characters than before, based on an article from MSDN which says that only certain characters cause an arg to require quoting. This seems to be incorrect, though, and worse it seems to be a difference in Windows version. The bot that fails is Windows 7, and I can't reproduce the failure on Win 10. But it's definitely related to quoting and special characters, because both tests that fail have a * in the argument, which is one of the special characters that would cause an argument to be quoted before but not any longer after the new patch. Since I don't have Win 7, all I can do is just guess that I need to restore the old quoting rules. So this patch does that in hopes that it fixes the problem on Windows 7. llvm-svn: 334375
* [X86] Remove GCCBuiltin from some intrinsics so we can custom handle them in ↵Craig Topper2018-06-101-72/+36
| | | | | | clang. llvm-svn: 334365
* [NEON] Support VST1xN intrinsics in AArch32 mode (LLVM part)Ivan A. Kosarev2018-06-101-0/+14
| | | | | | | | | We currently support them only in AArch64. The NEON Reference, however, says they are 'ARMv7, ARMv8' intrinsics. Differential Revision: https://reviews.llvm.org/D47447 llvm-svn: 334361
* [X86] Remove masking from the 512-bit masked floating point add/sub/mul/div ↵Craig Topper2018-06-101-16/+17
| | | | | | intrinsics. Use a select in IR instead. llvm-svn: 334358
* Cleanup. NFCFangrui Song2018-06-101-2/+1
| | | | llvm-svn: 334357
* Revert "Resubmit "[Support] Expose flattenWindowsCommandLine.""Zachary Turner2018-06-101-13/+0
| | | | | | | | | This reverts commit 65243b6d19143cb7a03f68df0169dcb63e8b4632. Seems like it's not a flake. It might have something to do with the '*' character being in a command line. llvm-svn: 334356
* Resubmit "[Support] Expose flattenWindowsCommandLine."Zachary Turner2018-06-101-0/+13
| | | | | | | | | There were a few linux compilation failures, but other than that I think this was just a flake that caused the tests to fail. I'm going to resubmit and see if the failures go away, if not I'll revert again. llvm-svn: 334355
* Revert "[Support] Expose flattenWindowsCommandLine."Zachary Turner2018-06-091-13/+0
| | | | | | | | | This reverts commit 10d2e88e87150a35dc367ba30716189d2af26774. This is causing some test failures for some reason, reverting while I investigate. llvm-svn: 334354
* [Support] Expose flattenWindowsCommandLine.Zachary Turner2018-06-091-0/+13
| | | | | | | | | | | This function was internal to Program.inc, but I've needed this on several occasions when I've had to use CreateProcess without llvm's sys::Execute functions. In doing so, I noticed that the function was written using unsafe C-string access and was pretty hard to understand / make sense of, so I've also re-written the functions to use more modern LLVM constructs. llvm-svn: 334353
* Use uniform mechanism for OOM errors handlingSerge Pavlov2018-06-094-40/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a recommit of r333506, which was reverted in r333518. The original commit message is below. In r325551 many calls of malloc/calloc/realloc were replaces with calls of their safe counterparts defined in the namespace llvm. There functions generate crash if memory cannot be allocated, such behavior facilitates handling of out of memory errors on Windows. If the result of *alloc function were checked for success, the function was not replaced with the safe variant. In these cases the calling function made the error handling, like: T *NewElts = static_cast<T*>(malloc(NewCapacity*sizeof(T))); if (NewElts == nullptr) report_bad_alloc_error("Allocation of SmallVector element failed."); Actually knowledge about the function where OOM occurred is useless. Moreover having a single entry point for OOM handling is convenient for investigation of memory problems. This change removes custom OOM errors handling and replaces them with calls to functions `llvm::safe_*alloc`. Declarations of `safe_*alloc` are moved to a separate include file, to avoid cyclic dependency in SmallVector.h Differential Revision: https://reviews.llvm.org/D47440 llvm-svn: 334344
* [X86] Remove GCCBuiltin from some intrinsics so we can do custom IR ↵Craig Topper2018-06-081-3/+0
| | | | | | generation from clang. llvm-svn: 334328
* [SCEV] Look through zero-extends in howFarToZeroKrzysztof Parzyszek2018-06-081-0/+3
| | | | | | | | | | | | An expression like (zext i2 {(trunc i32 (1 + %B) to i2),+,1}<%while.body> to i32) will become zero exactly when the nested value becomes zero in its type. Strip injective operations from the input value in howFarToZero to make the value simpler. Differential Revision: https://reviews.llvm.org/D47951 llvm-svn: 334318
* Clean up some code in Program.Zachary Turner2018-06-081-17/+14
| | | | | | | | | | NFC here, this just raises some platform specific ifdef hackery out of a class and creates proper platform-independent typedefs for the relevant things. This allows these typedefs to be reused in other places without having to reinvent this preprocessor logic. llvm-svn: 334294
OpenPOWER on IntegriCloud