summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Revert r333791 "Cap "voluntary" vector alignment at 16 for all Darwin ↵Reid Kleckner2018-06-042-3/+7
| | | | | | | | | | | | | | platforms." Adding __attribute__((aligned(32))) to __m256 breaks the implementation of _mm256_loadu_ps on Windows. On Windows, alignment attributes have higher precedence than packing attributes. We also might want to carefully consider the consequences of changing our vector typedefs, since many users copy them and invent their own new, non-Intel specific vector type names. llvm-svn: 333958
* This diff includes changes for supporting the following types.Leonard Chan2018-06-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | // Primary fixed point types signed short _Accum s_short_accum; signed _Accum s_accum; signed long _Accum s_long_accum; unsigned short _Accum u_short_accum; unsigned _Accum u_accum; unsigned long _Accum u_long_accum; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; This diff only allows for declaration of the 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. The saturated versions of these types and the equivalent _Fract types will also be added in future patches. The tests included are for asserting that we can declare these types. Fixed the test that was failing by not checking for dso_local on some targets. Differential Revision: https://reviews.llvm.org/D46084 llvm-svn: 333923
* Revert "This diff includes changes for supporting the following types."Leonard Chan2018-06-021-3/+0
| | | | | | | This reverts commit r333814, which fails for a test checking the bit width on ubuntu. llvm-svn: 333815
* This diff includes changes for supporting the following types.Leonard Chan2018-06-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | ``` // Primary fixed point types signed short _Accum s_short_accum; signed _Accum s_accum; signed long _Accum s_long_accum; unsigned short _Accum u_short_accum; unsigned _Accum u_accum; unsigned long _Accum u_long_accum; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; ``` This diff only allows for declaration of the 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. The saturated versions of these types and the equivalent `_Fract` types will also be added in future patches. The tests included are for asserting that we can declare these types. Differential Revision: https://reviews.llvm.org/D46084 llvm-svn: 333814
* Cap "voluntary" vector alignment at 16 for all Darwin platforms.John McCall2018-06-012-7/+3
| | | | | | | | | | | | | | | | | | | | | This fixes two major problems: - We were not capping vector alignment as desired on 32-bit ARM. - We were using different alignments based on the AVX settings on Intel, so we did not have a consistent ABI. This is an ABI break, but we think we can get away with it because vectors tend to be used mostly in inline code (which is why not having a consistent ABI has not proven disastrous on Intel). Intel's AVX types are specified as having 32-byte / 64-byte alignment, so align them explicitly instead of relying on the base ABI rule. Note that this sort of attribute is stripped from template arguments in template substitution, so there's a possibility that code templated over vectors will produce inadequately-aligned objects. The right long-term solution for this is for alignment attributes to be interpreted as true qualifiers and thus preserved in the canonical type. llvm-svn: 333791
* Add dump method for selectorsAditya Kumar2018-05-311-0/+2
| | | | | | | Differential Revision: https://reviews.llvm.org/D45935 Reviewers: compnerd llvm-svn: 333657
* [Sparc] Add floating-point register namesDaniel Cederman2018-05-301-1/+9
| | | | | | | | | | | | Reviewers: jyknight Reviewed By: jyknight Subscribers: eraman, fedor.sergeev, jrtc27, cfe-commits Differential Revision: https://reviews.llvm.org/D47137 llvm-svn: 333510
* Support Swift calling convention for PPC64 targetsBob Wilson2018-05-251-0/+9
| | | | | | | This adds basic support for the Swift calling convention with PPC64 targets. Patch provided by Atul Sowani in bug report #37223 llvm-svn: 333316
* [x86] invpcid intrinsicGabor Buella2018-05-252-0/+8
| | | | | | | | | | | | An intrinsic for an old instruction, as described in the Intel SDM. Reviewers: craig.topper, rnk Reviewed By: craig.topper, rnk Differential Revision: https://reviews.llvm.org/D47142 llvm-svn: 333256
* [VFS] Implement getRealPath in InMemoryFileSystem.Eric Liu2018-05-241-0/+13
| | | | | | | | | | Reviewers: bkramer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47262 llvm-svn: 333172
* [AST][ObjC] Print implicit property expression that only has a setter ↵Alex Lorenz2018-05-231-0/+6
| | | | | | | | without crashing rdar://40447209 llvm-svn: 333046
* [VFS] Implement getRealPath for OverlayFileSystem.Eric Liu2018-05-181-0/+9
| | | | | | | | | | Reviewers: bkramer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47060 llvm-svn: 332717
* This patch aims to match the changes introducedAlexander Ivchenko2018-05-183-28/+20
| | | | | | | | | | | | | | | | | in gcc by https://gcc.gnu.org/ml/gcc-cvs/2018-04/msg00534.html. The -mibt feature flag is being removed, and the -fcf-protection option now also defines a CET macro and causes errors when used on non-X86 targets, while X86 targets no longer check for -mibt and -mshstk to determine if -fcf-protection is supported. -mshstk is now used only to determine availability of shadow stack intrinsics. Comes with an LLVM patch (D46882). Patch by mike.dvoretsky Differential Revision: https://reviews.llvm.org/D46881 llvm-svn: 332704
* Use dotted format of version tuple for availability diagnosticsJan Korous2018-05-171-3/+3
| | | | | | | | | | | | E. g. use "10.11" instead of "10_11". We are maintaining backward compatibility by parsing underscore-delimited version tuples but no longer keep track of the separator and using dot format for output. Differential Revision: https://reviews.llvm.org/D46747 rdar://problem/39845032 llvm-svn: 332598
* Add vfs::FileSystem::getRealPathEric Liu2018-05-172-16/+15
| | | | | | | | | | | | | | Summary: And change `FileManager::getCanonicalName` to use getRealPath. Reviewers: bkramer Reviewed By: bkramer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46942 llvm-svn: 332590
* [Solaris] Only define _REENTRANT if -pthreadRainer Orth2018-05-151-1/+2
| | | | | | | | | | | | When looking at lib/Basic/Targets/OSTargets.h, I noticed that _REENTRANT is defined unconditionally on Solaris, unlike all other targets and what either Studio cc (only define it with -mt) or gcc (only define it with -pthread) do. This patch follows that lead. Differential Revision: https://reviews.llvm.org/D41241 llvm-svn: 332343
* [X86] ptwrite intrinsicGabor Buella2018-05-102-0/+8
| | | | | | | | | | Reviewers: craig.topper, RKSimon Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D46540 llvm-svn: 331962
* [CUDA] Added -f[no-]cuda-short-ptr optionArtem Belevich2018-05-091-0/+3
| | | | | | | | | The option enables use of 32-bit pointers for accessing const/local/shared memory. The feature is disabled by default. Differential Revision: https://reviews.llvm.org/D46148 llvm-svn: 331938
* Add SourceManagerForFile helper which sets up SourceManager and dependencies ↵Eric Liu2018-05-091-0/+26
| | | | | | | | | | | | | | | | for a single file with code snippet Summary: This can be used to create a virtual environment (incl. VFS, source manager) for code snippets. Reviewers: sammccall, klimek Reviewed By: sammccall Subscribers: klimek, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D46176 llvm-svn: 331923
* [OpenCL] Restrict various keywords in OpenCL C++ modeSven van Haastregt2018-05-091-3/+6
| | | | | | | | | | | | | | | | | | | | | | | Restrict the following keywords in the OpenCL C++ language mode, according to Sections 2.2 & 2.9 of the OpenCL C++ 1.0 Specification. - dynamic_cast - typeid - register (already restricted in OpenCL C, update the diagnostic) - thread_local - exceptions (try/catch/throw) - access qualifiers read_only, write_only, read_write Support the `__global`, `__local`, `__constant`, `__private`, and `__generic` keywords in OpenCL C++. Leave the unprefixed address space qualifiers such as global available, i.e., do not mark them as reserved keywords in OpenCL C++. libclcxx provides explicit address space pointer classes such as `global_ptr` and `global<T>` that are implemented using the `__`-prefixed qualifiers. Differential Revision: https://reviews.llvm.org/D46022 llvm-svn: 331874
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-0912-47/+47
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* [OpenCL] Factor out language version printingSven van Haastregt2018-05-081-0/+5
| | | | | | | | | Generate a printable OpenCL language version number in a single place and select between the OpenCL C or OpenCL C++ version accordingly. Differential Revision: https://reviews.llvm.org/D46382 llvm-svn: 331766
* [x86] Introduce the pconfig intrinsicGabor Buella2018-05-082-0/+8
| | | | | | | | | | Reviewers: craig.topper, zvi Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D46431 llvm-svn: 331740
* [X86] directstore and movdir64b intrinsicsGabor Buella2018-05-012-0/+16
| | | | | | | | | | Reviewers: spatel, craig.topper, RKSimon Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D45984 llvm-svn: 331249
* Implement P0482R2, support for char8_t type.Richard Smith2018-05-011-7/+9
| | | | | | | | | | | | This is not yet part of any C++ working draft, and so is controlled by the flag -fchar8_t rather than a -std= flag. (The GCC implementation is controlled by a flag with the same name.) This implementation is experimental, and will be removed or revised substantially to match the proposal as it makes its way through the C++ committee. llvm-svn: 331244
* AMDGPU: Add Vega12 and Vega20Matt Arsenault2018-04-302-2/+10
| | | | | | | | Changes by Matt Arsenault Konstantin Zhuravlyov llvm-svn: 331216
* [Targets] Implement getConstraintRegister for ARM and AArch64Mikhail Maltsev2018-04-302-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The getConstraintRegister method is used by semantic checking of inline assembly statements in order to diagnose conflicts between clobber list and input/output lists. Currently ARM and AArch64 don't override getConstraintRegister, so conflicts between registers assigned to variables in asm labels and clobber lists are not diagnosed. Such conflicts can cause assertion failures in the back end and even miscompilations. This patch implements getConstraintRegister for ARM and AArch64 targets. Since these targets don't have single-register constraints, the implementation is trivial and just returns the register specified in an asm label (if any). Reviewers: eli.friedman, javed.absar, thopre Reviewed By: thopre Subscribers: rengolin, eraman, rogfer01, myatsina, kristof.beyls, cfe-commits, chrib Differential Revision: https://reviews.llvm.org/D45965 llvm-svn: 331164
* PR37189 Fix incorrect end source location and spelling for a split '>>' token.Richard Smith2018-04-302-31/+26
| | | | | | | | | | | | | | | | | | When a '>>' token is split into two '>' tokens (in C++11 onwards), or (as an extension) when we do the same for other tokens starting with a '>', we can't just use a location pointing to the first '>' as the location of the split token, because that would result in our miscomputing the length and spelling for the token. As a consequence, for example, a refactoring replacing 'A<X>' with something else would sometimes replace one character too many, and similarly diagnostics highlighting a template-id source range would highlight one character too many. Fix this by creating an expansion range covering the first character of the '>>' token, whose spelling is '>'. For this to work, we generalize the expansion range of a macro FileID to be either a token range (the common case) or a character range (used in this new case). llvm-svn: 331155
* Revert r329698 (and r329702).Nico Weber2018-04-271-2/+16
| | | | | | | | | Speculative. ClangMoveTests started failing on http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/9958 after this change. I can't reproduce on my machine, let's see if it was due to this change. llvm-svn: 331077
* s/LLVM_ON_WIN32/_WIN32/, clangNico Weber2018-04-272-3/+3
| | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. llvm-svn: 331069
* [ARM] Add __ARM_FEATURE_DOTPROD pre-defined macroOliver Stannard2018-04-272-0/+7
| | | | | | | | | | | | | | This adds a pre-defined macro to test if the compiler has support for the v8.2-A dot rpoduct intrinsics in AArch32 mode. The AAcrh64 equivalent has already been added by rL330229. The ACLE spec which describes this macro hasn't been published yet, but this is based on the final internal draft, and GCC has already implemented this. Differential revision: https://reviews.llvm.org/D46108 llvm-svn: 331038
OpenPOWER on IntegriCloud