summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic
Commit message (Collapse)AuthorAgeFilesLines
* [VFS] vfs::directory_iterator yields path and file type instead of full StatusSam McCall2018-09-141-44/+37
| | | | | | | | | | | | | | | | | | | | | | | Summary: Most callers I can find are using only `getName()`. Type is used by the recursive iterator. Now we don't have to call stat() on every listed file (on most platforms). Exceptions are e.g. Solaris where readdir() doesn't include type information. On those platforms we'll still stat() - see D51918. The result is significantly faster (stat() can be slow). My motivation: this may allow us to improve clang IO on large TUs with long include search paths. Caching readdir() results may allow us to skip many stat() and open() operations on nonexistent files. Reviewers: bkramer Subscribers: fedor.sergeev, cfe-commits Differential Revision: https://reviews.llvm.org/D51921 llvm-svn: 342232
* When we leave a module header, make that header visible in itsRichard Smith2018-09-121-6/+5
| | | | | | includer's context, even if its overall module is unavailable. llvm-svn: 342096
* Move AESNI generation to Skylake and GoldmontErich Keane2018-09-101-2/+2
| | | | | | | | | | | | | | | | | | | The instruction set first appeared with Westmere, but not all processors in that and the next few generations have the instructions. According to Wikipedia[1], the first generation in which all SKUs have AES instructions are Skylake and Goldmont. I can't find any Skylake, Kabylake, Kabylake-R or Cannon Lake currently listed at https://ark.intel.com that says "Intel® AES New Instructions" "No". This matches GCC commit https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01940.html [1] https://en.wikipedia.org/wiki/AES_instruction_set Patch By: thiagomacieira Differential Revision: https://reviews.llvm.org/D51510 llvm-svn: 341862
* [VFS] Cache the current working directory for the real FS.Eric Liu2018-09-051-2/+16
| | | | | | | | | | Reviewers: sammccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D51641 llvm-svn: 341455
* Adding HardLink Support to VirtualFileSystem.Ilya Biryukov2018-09-041-49/+119
| | | | | | | | | | | | | | | | | | | | | | | Summary: Added support of creating a hardlink from one file to another file. After a hardlink is added between two files, both file will have the same: 1. UniqueID (inode) 2. Size 3. Buffer This will bring replay of compilation closer to the actual compilation. There are instances where clang checks for the UniqueID of the file/header to be loaded which leads to a different behavior during replay as all files have different UniqueIDs. Patch by Utkarsh Saxena! Reviewers: ilya-biryukov Reviewed By: ilya-biryukov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D51359 llvm-svn: 341366
* Add dump() method for SourceRangeStephen Kelly2018-08-301-0/+54
| | | | | | | | Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50662 llvm-svn: 341140
* [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
OpenPOWER on IntegriCloud