summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic
Commit message (Collapse)AuthorAgeFilesLines
* [ARM] Set __ARM_FEATURE_SIMD32 for +dsp coresSam Parker2018-08-291-1/+1
| | | | | | | | | | | | | | ARM_FEATURE_DSP is already set for targets with the +dsp feature. In the backend, this target feature is also used to represent the availability of the of the instructions that the ACLE guard through the __ARM_FEATURE_SIMD32 macro. We don't have any cores that implement one and not the other, so set this macro for cores later than V6 or for Cortex-M cores that the target parser, or user, reports that the 'dsp' instructions are supported. Differential Revision: https://reviews.llvm.org/D51093 llvm-svn: 340911
* Revert r323281 "Adjust MaxAtomicInlineWidth for i386/i486 targets."Hans Wennborg2018-08-241-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | As reported on http://lists.llvm.org/pipermail/cfe-dev/2018-August/058760.html, this broke i386-freebsd11 due to its lack of atomic 64 bit primitives. While that's not really this commit's fault, let's revert back to the old behaviour until this can be fixed. This means generating cmpxchg8b etc for i386 and i486 which don't technically support those, but that's been the behaviour for a long time, so a little longer probably doesn't hurt that much. > Adjust MaxAtomicInlineWidth for i386/i486 targets. > > This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6. > Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. However, > i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg. > So in this patch MaxAtomicInlineWidth is reset as follows: > For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported. > For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg. > For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b. > > Differential Revision: https://reviews.llvm.org/D42154 llvm-svn: 340666
* Fix build bot after r340598.Eric Liu2018-08-241-8/+12
| | | | | | | Revert to the original behavior: only calculate real file path when file is opened and avoid using InterndPath for real path calculation. llvm-svn: 340602
* [FileManager] Do not call 'real_path' in getFile().Eric Liu2018-08-241-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This partially rolls back the change in D48903: https://github.com/llvm-mirror/clang/commit/89aa7f45a1f728144935289d4ce69d8522999de0#diff-0025af005307891b5429b6a834823d5eR318 `real_path` can be very expensive on real file systems, and calling it on each opened file can slow down the compilation. This also slows down deserialized ASTs for which real paths need to be recalculated for each input files again. For clangd code completion latency (using preamble): Before {F7039629} After {F7039630} Reviewers: ilya-biryukov, simark Reviewed By: ilya-biryukov Subscribers: kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D51159 llvm-svn: 340598
* [x86/retpoline] Split the LLVM concept of retpolines into separateChandler Carruth2018-08-232-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | subtarget features for indirect calls and indirect branches. This is in preparation for enabling *only* the call retpolines when using speculative load hardening. I've continued to use subtarget features for now as they continue to seem the best fit given the lack of other retpoline like constructs so far. The LLVM side is pretty simple. I'd like to eventually get rid of the old feature, but not sure what backwards compatibility issues that will cause. This does remove the "implies" from requesting an external thunk. This always seemed somewhat questionable and is now clearly not desirable -- you specify a thunk the same way no matter which set of things are getting retpolines. I really want to keep this nicely isolated from end users and just an LLVM implementation detail, so I've moved the `-mretpoline` flag in Clang to no longer rely on a specific subtarget feature by that name and instead to be directly handled. In some ways this is simpler, but in order to preserve existing behavior I've had to add some fallback code so that users who relied on merely passing -mretpoline-external-thunk continue to get the same behavior. We should eventually remove this I suspect (we have never tested that it works!) but I've not done that in this patch. Differential Revision: https://reviews.llvm.org/D51150 llvm-svn: 340515
* [clang][mips] Set __mips_fpr correctly for -mfpxxStefan Maksimovic2018-08-222-16/+63
| | | | | | | | | | | | | | | | | | | | Set __mips_fpr to 0 if o32 ABI is used with either -mfpxx or none of -mfp32, -mfpxx, -mfp64 being specified. Introduce additional checks: -mfpxx is only to be used in conjunction with the o32 ABI. report an error when incompatible options are provided. Formerly no errors were raised when combining n32/n64 ABIs with -mfp32 and -mfpxx. There are other cases when __mips_fpr should be set to 0 that are not covered, ex. using o32 on a mips64 cpu which is valid but not supported in the backend as of yet. Differential Revision: https://reviews.llvm.org/D50557 llvm-svn: 340391
* AMDGPU: Move target code into TargetParserMatt Arsenault2018-08-212-193/+77
| | | | llvm-svn: 340292
* AMDGPU: Correct errors in device tableMatt Arsenault2018-08-161-2/+2
| | | | llvm-svn: 339934
* Add a newline to SourceLocation dump outputStephen Kelly2018-08-152-3/+4
| | | | | | | | | | | | | | Summary: Migrate callers to print(). dump() should be useful to downstreams and third parties as a debugging aid. Everyone trips up on this and creates confusing output. Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50661 llvm-svn: 339810
* AMDGPU: Fix enabling denormals by default on pre-VI targetsMatt Arsenault2018-08-082-66/+68
| | | | | | | | Fast FMAF is not a sufficient condition to enable denormals. Before VI, enabling denormals caused F32 instructions to run at F64 speeds. llvm-svn: 339278
* [NFC][VFS] Fix typos in comments.Volodymyr Sapsai2018-08-081-2/+2
| | | | llvm-svn: 339215
* [VFS] Unify iteration code for VFSFromYamlDirIterImpl, NFC intended.Volodymyr Sapsai2018-08-071-19/+10
| | | | | | | | | | | | | | First and subsequent iteration steps are similar, capture this similarity. Reviewers: bruno, benlangmuir Reviewed By: bruno Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50118 llvm-svn: 339199
* [VFS] Emit an error when entry at root level uses a relative path.Volodymyr Sapsai2018-08-071-3/+15
| | | | | | | | | | | | | | | | | | | | | Entries with only a filename prevent us from building a file system tree and cause the assertion > Assertion failed: (NewParentE && "Parent entry must exist"), function uniqueOverlayTree, file clang/lib/Basic/VirtualFileSystem.cpp, line 1303. Entries with a relative path are simply not discoverable during header search. rdar://problem/28990865 Reviewers: bruno, benlangmuir Reviewed By: bruno Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D49518 llvm-svn: 339164
* AMDGPU: Add builtin for s_dcache_wbMatt Arsenault2018-08-071-0/+1
| | | | llvm-svn: 339110
* AMDGPU: Add builtin for s_dcache_inv_volMatt Arsenault2018-08-071-1/+3
| | | | llvm-svn: 339109
* [VirtualFileSystem] InMemoryFileSystem::status: Return a Status with the ↵Simon Marchi2018-08-062-17/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | requested name Summary: InMemoryFileSystem::status behaves differently than RealFileSystem::status. The Name contained in the Status returned by RealFileSystem::status will be the path as requested by the caller, whereas InMemoryFileSystem::status returns the normalized path. For example, when requested the status for "../src/first.h", RealFileSystem returns a Status with "../src/first.h" as the Name. InMemoryFileSystem returns "/absolute/path/to/src/first.h". The reason for this change is that I want to make a unit test in the clangd testsuite (where we use an InMemoryFileSystem) to reproduce a bug I get with the clangd program (where a RealFileSystem is used). This difference in behavior "hides" the bug in the unit test version. An indirect impact of this change is that a -Wnonportable-include-path warning is now emitted in test PCH/case-insensitive-include.c. This is because the real path of the included file (with the wrong case) was not available previously, whereas it is now. Reviewers: malaperle, ilya-biryukov, bkramer Reviewed By: ilya-biryukov Subscribers: eric_niebler, malaperle, omtcyfz, hokein, bkramer, ilya-biryukov, ioeric, cfe-commits Differential Revision: https://reviews.llvm.org/D48903 llvm-svn: 339063
* Fix for broken build on clang-hexagon-elf for ambiguous call toLeonard Chan2018-08-061-1/+2
| | | | | | std::abs. llvm-svn: 339044
* [Fixed Point Arithmetic] Remove unused include.Benjamin Kramer2018-08-061-1/+0
| | | | | | lib/Basic cannot depend on lib/AST. llvm-svn: 339031
* [Fixed Point Arithmetic] Fixed Point ConstantLeonard Chan2018-08-062-0/+116
| | | | | | | | | | This patch proposes an abstract type that represents fixed point numbers, similar to APInt or APSInt that was discussed in https://reviews.llvm.org/D48456#inline-425585. This type holds a value, scale, and saturation and is meant to perform intermediate calculations on constant fixed point values. Currently this class is used as a way for handling the conversions between fixed point numbers with different sizes and radixes. For example, if I'm casting from a signed _Accum to a saturated unsigned short _Accum, I will need to check the value of the signed _Accum to see if it fits into the short _Accum which involves getting and comparing against the max/min values of the short _Accum. The FixedPointNumber class currently handles the radix shifting and extension when converting to a signed _Accum. Differential Revision: https://reviews.llvm.org/D48661 llvm-svn: 339028
* Try to make builtin address space declarations not uselessMatt Arsenault2018-08-021-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way address space declarations for builtins currently work is nearly useless. The code assumes the address spaces used for builtins is a confusingly named "target address space" from user code using __attribute__((address_space(N))) that matches the builtin declaration. There's no way to use this to declare a builtin that returns a language specific address space. The terminology used is highly cofusing since it has nothing to do with the the address space selected by the target to use for a language address space. This feature is essentially unused as-is. AMDGPU and NVPTX are the only in-tree targets attempting to use this. The AMDGPU builtins certainly do not behave as intended (i.e. all of the builtins returning pointers can never compile because the numbered address space never matches the expected named address space). The NVPTX builtins are missing tests for some, and the others seem to rely on an implicit addrspacecast. Change the used address space for builtins based on a target hook to allow using a language address space for a builtin. This allows the same builtin declaration to be used for multiple languages with similarly purposed address spaces (e.g. the same AMDGPU builtin can be used in OpenCL and CUDA even though the constant address spaces are arbitarily different). This breaks the possibility of using arbitrary numbered address spaces alongside the named address spaces for builtins. If this is an issue we probably need to introduce another builtin declaration character to distinguish language address spaces from so-called "target address spaces". llvm-svn: 338707
* [Android] Increase default new alignment for AndroidPirama Arumuga Nainar2018-08-011-2/+3
| | | | | | | | | | | | | | Summary: Android's memory allocators also guarantee 8-byte alignment for 32-bit architectures and 16-byte alignment for 64-bit. Reviewers: rsmith Subscribers: cfe-commits, srhines, enh Differential Revision: https://reviews.llvm.org/D50112 llvm-svn: 338603
* [AArch64][ARM] Add Armv8.4-A testsSjoerd Meijer2018-08-011-0/+4
| | | | | | | | | This adds tests for Armv8.4-A, and also some v8.2 and v8.3 tests that were missing. Differential Revision: https://reviews.llvm.org/D50068 llvm-svn: 338525
* Remove trailing spaceFangrui Song2018-07-3012-91/+91
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* Revert r338057 "[VirtualFileSystem] InMemoryFileSystem::status: Return a ↵Reid Kleckner2018-07-262-56/+17
| | | | | | | | Status with the requested name" This broke clang/test/PCH/case-insensitive-include.c on Windows. llvm-svn: 338084
* [ARM64] [Windows] Follow MS X86_64 C++ ABI when passing structsSanjin Sijaric2018-07-263-1/+8
| | | | | | | | | | | | | | | | | Summary: Microsoft's C++ object model for ARM64 is the same as that for X86_64. For example, small structs with non-trivial copy constructors or virtual function tables are passed indirectly. Currently, they are passed in registers when compiled with clang. Reviewers: rnk, mstorsjo, TomTan, haripul, javed.absar Reviewed By: rnk, mstorsjo Subscribers: kristof.beyls, chrib, llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D49770 llvm-svn: 338076
* [VirtualFileSystem] InMemoryFileSystem::status: Return a Status with the ↵Simon Marchi2018-07-262-17/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | requested name Summary: InMemoryFileSystem::status behaves differently than RealFileSystem::status. The Name contained in the Status returned by RealFileSystem::status will be the path as requested by the caller, whereas InMemoryFileSystem::status returns the normalized path. For example, when requested the status for "../src/first.h", RealFileSystem returns a Status with "../src/first.h" as the Name. InMemoryFileSystem returns "/absolute/path/to/src/first.h". The reason for this change is that I want to make a unit test in the clangd testsuite (where we use an InMemoryFileSystem) to reproduce a bug I get with the clangd program (where a RealFileSystem is used). This difference in behavior "hides" the bug in the unit test version. Reviewers: malaperle, ilya-biryukov, bkramer Subscribers: cfe-commits, ioeric, ilya-biryukov, bkramer, hokein, omtcyfz Differential Revision: https://reviews.llvm.org/D48903 llvm-svn: 338057
* Revert "[VFS] Cleanups to VFS interfaces."Jordan Rupprecht2018-07-242-20/+19
| | | | | | This reverts commit r337834 due to test failures. llvm-svn: 337850
* [VFS] Cleanups to VFS interfaces.Sam McCall2018-07-242-19/+20
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: - add comments clarifying semantics - Status::copyWithNewName(Status, Name) --> instance method - Status::copyWithNewName(fs::file_status, Name) --> constructor (it's not a copy) - File::getName() -> getRealPath(), reflecting its actual behavior/function and stop returning status().getName() in the base class (callers can do this fallback if they want to, it complicates the contracts). This is mostly NFC, but the behavior of File::getName() affects FileManager's FileEntry::tryGetRealPathName(), which now fails in more cases: - non-real file cases - real-file cases where the underlying vfs::File was opened in a way that doesn't call realpath(). (In these cases we don't know a distinct real name, so in principle it seems OK) Reviewers: klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49724 llvm-svn: 337834
* [WebAssembly] Change size_t to `unsigned long`.Dan Gohman2018-07-241-3/+5
| | | | | | | | | | | | Changing it to unsigned long (which is 32-bit on wasm32) makes it the same type as wasm64 (where unsigned long is 64-bit), which would eliminate the most common cause for mangled names being different between wasm32 and wasm64. For example, export lists containing symbol names could now often be the same between wasm32 and wasm64. Differential Revision: https://reviews.llvm.org/D40526 llvm-svn: 337783
* NFC: Add the emacs c++ mode hint "-*- C++ -*-" to the headers that don't have itErik Pilkington2018-07-242-2/+2
| | | | | | https://llvm.org/docs/CodingStandards.html#file-headers llvm-svn: 337780
* [MS] Update _MSVC_LANG values for C++17 and C++2aReid Kleckner2018-07-231-2/+4
| | | | | | Fixes PR38262 llvm-svn: 337715
* Implement cpu_dispatch/cpu_specific MultiversioningErich Keane2018-07-202-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As documented here: https://software.intel.com/en-us/node/682969 and https://software.intel.com/en-us/node/523346. cpu_dispatch multiversioning is an ICC feature that provides for function multiversioning. This feature is implemented with two attributes: First, cpu_specific, which specifies the individual function versions. Second, cpu_dispatch, which specifies the location of the resolver function and the list of resolvable functions. This is valuable since it provides a mechanism where the resolver's TU can be specified in one location, and the individual implementions each in their own translation units. The goal of this patch is to be source-compatible with ICC, so this implementation diverges from the ICC implementation in a few ways: 1- Linux x86/64 only: This implementation uses ifuncs in order to properly dispatch functions. This is is a valuable performance benefit over the ICC implementation. A future patch will be provided to enable this feature on Windows, but it will obviously more closely fit ICC's implementation. 2- CPU Identification functions: ICC uses a set of custom functions to identify the feature list of the host processor. This patch uses the cpu_supports functionality in order to better align with 'target' multiversioning. 1- cpu_dispatch function def/decl: ICC's cpu_dispatch requires that the function marked cpu_dispatch be an empty definition. This patch supports that as well, however declarations are also permitted, since the linker will solve the issue of multiple emissions. Differential Revision: https://reviews.llvm.org/D47474 llvm-svn: 337552
* [AArch64] Define TARGET_HEADER_BUILTINMartin Storsjo2018-07-181-0/+2
| | | | | | | Without it, the new intrinsics became available for all language variants. This was missed in SVN r337327. llvm-svn: 337352
* Always use __mcount on NetBSD. Some platforms don't provide _mcount.Joerg Sonnenberger2018-07-171-1/+1
| | | | llvm-svn: 337277
* By popular demand, switch in64_t on NetBSD/AArch64 and NetBSD/PowerPC64Joerg Sonnenberger2018-07-172-9/+2
| | | | | | to long for consistency with other 64bit platforms. llvm-svn: 337271
* [Hexagon] Diagnose intrinsics not supported by selected CPU/HVXKrzysztof Parzyszek2018-07-121-0/+4
| | | | llvm-svn: 336933
* Revert "[VirtualFileSystem] InMemoryFileSystem::status: Return a Status with ↵Eric Liu2018-07-112-61/+19
| | | | | | | | | | the requested name" This reverts commit r336807. This breaks users of ClangTool::mapVirtualFile. Will try to investigate a fix. See also the discussion on https://reviews.llvm.org/D48903 llvm-svn: 336831
* [VirtualFileSystem] InMemoryFileSystem::status: Return a Status with the ↵Simon Marchi2018-07-112-19/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | requested name Summary: InMemoryFileSystem::status behaves differently than RealFileSystem::status. The Name contained in the Status returned by RealFileSystem::status will be the path as requested by the caller, whereas InMemoryFileSystem::status returns the normalized path. For example, when requested the status for "../src/first.h", RealFileSystem returns a Status with "../src/first.h" as the Name. InMemoryFileSystem returns "/absolute/path/to/src/first.h". The reason for this change is that I want to make a unit test in the clangd testsuite (where we use an InMemoryFileSystem) to reproduce a bug I get with the clangd program (where a RealFileSystem is used). This difference in behavior "hides" the bug in the unit test version. In general, I guess it's good if InMemoryFileSystem works as much as possible like RealFileSystem. Doing so made the FileEntry::RealPathName value (assigned in FileManager::getFile) wrong when using the InMemoryFileSystem. That's because it assumes that vfs::File::getName will always return the real path. I changed to to use FileSystem::getRealPath instead. Subscribers: ilya-biryukov, ioeric, cfe-commits Differential Revision: https://reviews.llvm.org/D48903 llvm-svn: 336807
* [Builtins][Attributes][X86] Tag all X86 builtins with their required vector ↵Craig Topper2018-07-091-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | width. Add a min_vector_width function attribute and tag all x86 instrinsics with it This is part of an ongoing attempt at making 512 bit vectors illegal in the X86 backend type legalizer due to CPU frequency penalties associated with wide vectors on Skylake Server CPUs. We want the loop vectorizer to be able to emit IR containing wide vectors as intermediate operations in vectorized code and allow these wide vectors to be legalized to 256 bits by the X86 backend even though we are targetting a CPU that supports 512 bit vectors. This is similar to what happens with an AVX2 CPU, the vectorizer can emit wide vectors and the backend will split them. We want this splitting behavior, but still be able to use new Skylake instructions that work on 256-bit vectors and support things like masking and gather/scatter. Of course if the user uses explicit vector code in their source code we need to not split those operations. Especially if they have used any of the 512-bit vector intrinsics from immintrin.h. And we need to make it so that merely using the intrinsics produces the expected code in order to be backwards compatible. To support this goal, this patch adds a new IR function attribute "min-legal-vector-width" that can indicate the need for a minimum vector width to be legal in the backend. We need to ensure this attribute is set to the largest vector width needed by any intrinsics from immintrin.h that the function uses. The inliner will be reponsible for merging this attribute when a function is inlined. We may also need a way to limit inlining in the future as well, but we can discuss that in the future. To make things more complicated, there are two different ways intrinsics are implemented in immintrin.h. Either as an always_inline function containing calls to builtins(can be target specific or target independent) or vector extension code. Or as a macro wrapper around a taget specific builtin. I believe I've removed all cases where the macro was around a target independent builtin. To support the always_inline function case this patch adds attribute((min_vector_width(128))) that can be used to tag these functions with their vector width. All x86 intrinsic functions that operate on vectors have been tagged with this attribute. To support the macro case, all x86 specific builtins have also been tagged with the vector width that they require. Use of any builtin with this property will implicitly increase the min_vector_width of the function that calls it. I've done this as a new property in the attribute string for the builtin rather than basing it on the type string so that we can opt into it on a per builtin basis and avoid any impact to target independent builtins. There will be future work to support vectors passed as function arguments and supporting inline assembly. And whatever else we can find that isn't covered by this patch. Special thanks to Chandler who suggested this direction and reviewed a preview version of this patch. And thanks to Eric Christopher who has had many conversations with me about this issue. Differential Revision: https://reviews.llvm.org/D48617 llvm-svn: 336583
* [Fixed Point Arithmetic] Rename `-fsame-fbits` flagLeonard Chan2018-06-291-2/+2
| | | | | | | | | | | - Rename the `-fsame-fbits` flag to `-fpadding-on-unsigned-fixed-point` - Move the flag from a driver option to a cc1 option - Rename the `SameFBits` member in TargetInfo to `PaddingOnUnsignedFixedPoint` - Updated descriptions Differential Revision: https://reviews.llvm.org/D48727 llvm-svn: 335993
* Use Triple::isMIPS() instead of enumerating all Triples. NFCAlexander Richardson2018-06-252-13/+4
| | | | | | | | Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D48549 llvm-svn: 335495
* [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point LiteralsLeonard Chan2018-06-202-3/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This diff includes the logic for setting the precision bits for each primary fixed point type in the target info and logic for initializing a fixed point literal. Fixed point literals are declared using the suffixes ``` hr: short _Fract uhr: unsigned short _Fract r: _Fract ur: unsigned _Fract lr: long _Fract ulr: unsigned long _Fract hk: short _Accum uhk: unsigned short _Accum k: _Accum uk: unsigned _Accum ``` Errors are also thrown for illegal literal values ``` unsigned short _Accum u_short_accum = 256.0uhk; // expected-error{{the integral part of this literal is too large for this unsigned _Accum type}} ``` Differential Revision: https://reviews.llvm.org/D46915 llvm-svn: 335148
* [SPIR] Prevent SPIR targets from using half conversion intrinsicsSjoerd Meijer2018-06-201-0/+5
| | | | | | | | | | | | | | | | | | | | | The SPIR target currently allows for half precision floating point types to be emitted using the LLVM intrinsic functions which convert half types to floats and doubles. However, this is illegal in SPIR as the only intrinsic allowed by SPIR is memcpy, as per section 3 of the SPIR specification. Currently this is leading to an assert being hit in the Clang CodeGen when attempting to emit a constant or literal _Float16 type in a comparison operation on a SPIR or SPIR64 target. This assert stems from the CodeGen attempting to emit a constant half value as an integer because the backend has specified that it is using these half conversion intrinsics (which represents half as i16). This patch prevents SPIR targets from using these intrinsics by overloading the responsible target info method, marks SPIR targets as having a legal half type and provides additional regression testing for the _Float16 type on SPIR targets. Patch by: Stephen McGroarty Differential Revision: https://reviews.llvm.org/D48188 llvm-svn: 335111
* bpf: recognize target specific option -mattr=dwarfris in clangYonghong Song2018-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The following is the usage example with clang: bash-4.2$ clang -target bpf -O2 -g -c -Xclang -target-feature -Xclang +dwarfris t.c bash-4.2$ llvm-objdump -S -d t.o t.o: file format ELF64-BPF Disassembly of section .text: test: ; int test(void) { 0: b7 00 00 00 00 00 00 00 r0 = 0 ; return 0; 1: 95 00 00 00 00 00 00 00 exit bash-4.2$ cat t.c int test(void) { return 0; } bash-4.2$ Signed-off-by: Yonghong Song <yhs@fb.com> llvm-svn: 334839
* [Fixed Point Arithmetic] Addition of the remaining fixed point types and ↵Leonard Chan2018-06-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | their saturated equivalents This diff includes changes for the remaining _Fract and _Sat fixed point types. ``` signed short _Fract s_short_fract; signed _Fract s_fract; signed long _Fract s_long_fract; unsigned short _Fract u_short_fract; unsigned _Fract u_fract; unsigned long _Fract u_long_fract; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; short _Fract short_fract; _Fract fract; long _Fract long_fract; // Saturated fixed point types _Sat signed short _Accum sat_s_short_accum; _Sat signed _Accum sat_s_accum; _Sat signed long _Accum sat_s_long_accum; _Sat unsigned short _Accum sat_u_short_accum; _Sat unsigned _Accum sat_u_accum; _Sat unsigned long _Accum sat_u_long_accum; _Sat signed short _Fract sat_s_short_fract; _Sat signed _Fract sat_s_fract; _Sat signed long _Fract sat_s_long_fract; _Sat unsigned short _Fract sat_u_short_fract; _Sat unsigned _Fract sat_u_fract; _Sat unsigned long _Fract sat_u_long_fract; // Aliased saturated fixed point types _Sat short _Accum sat_short_accum; _Sat _Accum sat_accum; _Sat long _Accum sat_long_accum; _Sat short _Fract sat_short_fract; _Sat _Fract sat_fract; _Sat long _Fract sat_long_fract; ``` This diff only allows for declaration of these fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. Differential Revision: https://reviews.llvm.org/D46911 llvm-svn: 334718
* [Basic] Fix -Wreorder warningBenjamin Kramer2018-06-131-15/+12
| | | | | | Just use field initializers that don't suffer from this problem llvm-svn: 334619
* [PowerPC] The __float128 type should only be available on Power9Stefan Pintilie2018-06-132-114/+105
| | | | | | | | | | | | Diasble the use of the type __float128 for PPC machines older than Power9. The use of -mfloat128 for PPC machine older than Power9 will result in an error. Differential Revision: https://reviews.llvm.org/D48088 llvm-svn: 334613
* Move VersionTuple from clang/Basic to llvm/SupportPavel Labath2018-06-113-102/+1
| | | | | | | | | | | | | | | | | | | | | | | 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
* [FileSystem] Split up the OpenFlags enumeration.Zachary Turner2018-06-071-1/+2
| | | | | | | | | | | | | | | | | This breaks the OpenFlags enumeration into two separate enumerations: OpenFlags and CreationDisposition. The first controls the behavior of the API depending on whether or not the target file already exists, and is not a flags-based enum. The second controls more flags-like values. This yields a more easy to understand API, while also allowing flags to be passed to the openForRead api, where most of the values didn't make sense before. This also makes the apis more testable as it becomes easy to enumerate all the configurations which make sense, so I've added many new tests to exercise all the different values. llvm-svn: 334221
* [Frontend] Honor UserFilesAreVolatile flag getting file buffer in ASTUnitIvan Donchevskii2018-06-061-3/+3
| | | | | | | | | Do not memory map the main file if the flag UserFilesAreVolatile is set to true in ASTUnit when calling FileSystem::getBufferForFile. Differential Revision: https://reviews.llvm.org/D47460 llvm-svn: 334070
OpenPOWER on IntegriCloud