summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/TargetInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [NFC] Remove unused variableDenis Bakhvalov2019-07-191-1/+1
| | | | | Change-Id: I5aee24dcdf6eebfbf788e52be22463387f23d927 llvm-svn: 366620
* [RISCV] Hard float ABI supportAlex Bradbury2019-07-181-13/+276
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The RISC-V hard float calling convention requires the frontend to: * Detect cases where, once "flattened", a struct can be passed using int+fp or fp+fp registers under the hard float ABI and coerce to the appropriate type(s) * Track usage of GPRs and FPRs in order to gate the above, and to determine when signext/zeroext attributes must be added to integer scalars This patch attempts to do this in compliance with the documented ABI, and uses ABIArgInfo::CoerceAndExpand in order to do this. @rjmccall, as author of that code I've tagged you as reviewer for initial feedback on my usage. Note that a previous version of the ABI indicated that when passing an int+fp struct using a GPR+FPR, the int would need to be sign or zero-extended appropriately. GCC never did this and the ABI was changed, which makes life easier as ABIArgInfo::CoerceAndExpand can't currently handle sign/zero-extension attributes. Re-landed after backing out 366450 due to missed hunks. Differential Revision: https://reviews.llvm.org/D60456 llvm-svn: 366480
* Revert "[RISCV] Hard float ABI support" r366450Alex Bradbury2019-07-181-272/+13
| | | | | | The commit was missing a few hunks. Will fix and recommit. llvm-svn: 366454
* [RISCV] Hard float ABI supportAlex Bradbury2019-07-181-13/+272
| | | | | | | | | | | | | | | | | | | | | | | | | | The RISC-V hard float calling convention requires the frontend to: * Detect cases where, once "flattened", a struct can be passed using int+fp or fp+fp registers under the hard float ABI and coerce to the appropriate type(s) * Track usage of GPRs and FPRs in order to gate the above, and to determine when signext/zeroext attributes must be added to integer scalars This patch attempts to do this in compliance with the documented ABI, and uses ABIArgInfo::CoerceAndExpand in order to do this. @rjmccall, as author of that code I've tagged you as reviewer for initial feedback on my usage. Note that a previous version of the ABI indicated that when passing an int+fp struct using a GPR+FPR, the int would need to be sign or zero-extended appropriately. GCC never did this and the ABI was changed, which makes life easier as ABIArgInfo::CoerceAndExpand can't currently handle sign/zero-extension attributes. Differential Revision: https://reviews.llvm.org/D60456 llvm-svn: 366450
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* [clang] Preserve names of addrspacecast'ed values.Vyacheslav Zakharin2019-07-101-1/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D63846 llvm-svn: 365666
* [AMDGPU] Increased the number of implicit argument bytes for both OpenCL and ↵Christudasan Devadasan2019-07-101-1/+1
| | | | | | | | | | | | | HIP (CLANG). To enable a new implicit kernel argument, increased the number of argument bytes from 48 to 56. Reviewed By: yaxunl Differential Revision: https://reviews.llvm.org/D63756 llvm-svn: 365643
* [HIP] Support attribute hip_pinned_shadowYaxun Liu2019-06-261-2/+14
| | | | | | | | | | | | | | | This patch introduces support of hip_pinned_shadow variable for HIP. A hip_pinned_shadow variable is a global variable with attribute hip_pinned_shadow. It has external linkage on device side and has no initializer. It has internal linkage on host side and has initializer or static constructor. It can be accessed in both device code and host code. This allows HIP runtime to implement support of HIP texture reference. Differential Revision: https://reviews.llvm.org/D62738 llvm-svn: 364381
* Fix passing structs and AVX vectors through sysv_abiReid Kleckner2019-06-201-8/+18
| | | | | | | | Do this the same way we did it for ms_abi in r324594. Fixes PR36806. llvm-svn: 363973
* Revert r363116 "[X86] [ABI] Fix i386 ABI "__m64" type bug"Hans Wennborg2019-06-191-36/+20
| | | | | | | | | | | | | | | | | | | | | This introduced MMX instructions in code that wasn't previously using them, breaking programs using 64-bit vectors and x87 floating-point in the same application. See discussion on the code review for more details. > According to System V i386 ABI: the __m64 type paramater and return > value are passed by MMX registers. But current implementation treats > __m64 as i64 which results in parameter passing by stack and returning > by EDX and EAX. > > This patch fixes the bug (https://bugs.llvm.org/show_bug.cgi?id=41029) > for Linux and NetBSD. > > Patch by Wei Xiao (wxiao3) > > Differential Revision: https://reviews.llvm.org/D59744 llvm-svn: 363790
* [OPENMP][NVPTX]Correct codegen for 128 bit long double.Alexey Bataev2019-06-181-1/+3
| | | | | | If the host uses 128 bit long doubles, the compiler should generate correct code for NVPTX devices. If the return type has 128 bit long doubles, in LLVM IR this type must be coerced to int array instead. llvm-svn: 363720
* [CodeGen][ARM] Fix FP16 vector coercionMikhail Maltsev2019-06-181-3/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When a function argument or return type is a homogeneous aggregate which contains an FP16 vector but the target does not support FP16 operations natively, the type must be converted into an array of integer vectors by then front end (otherwise LLVM will handle FP16 vectors incorrectly by scalarizing them and promoting FP16 to float, see https://reviews.llvm.org/D50507). Currently the logic for checking whether or not a given homogeneous aggregate contains FP16 vectors is incorrect: it only looks at the type of the first vector. This patch fixes the issue by adding a new method ARMABIInfo::containsAnyFP16Vectors and using it. The traversal logic of this method is largely the same as in ABIInfo::isHomogeneousAggregate. Reviewers: eli.friedman, olista01, ostannard Reviewed By: ostannard Subscribers: ostannard, john.brawn, javed.absar, kristof.beyls, pbarrio, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63437 llvm-svn: 363687
* [AMDGPU] Enable the implicit arguments for HIP (CLANG)Yaxun Liu2019-06-141-1/+2
| | | | | | | | Enable 48-bytes of implicit arguments for HIP as well. Earlier it was enabled for OpenCL. This code is specific to AMDGPU target. Differential Revision: https://reviews.llvm.org/D62244 llvm-svn: 363414
* [X86] [ABI] Fix i386 ABI "__m64" type bugPengfei Wang2019-06-121-20/+36
| | | | | | | | | | | | | | | | According to System V i386 ABI: the __m64 type paramater and return value are passed by MMX registers. But current implementation treats __m64 as i64 which results in parameter passing by stack and returning by EDX and EAX. This patch fixes the bug (https://bugs.llvm.org/show_bug.cgi?id=41029) for Linux and NetBSD. Patch by Wei Xiao (wxiao3) Differential Revision: https://reviews.llvm.org/D59744 llvm-svn: 363116
* Revert "[X86] Fix i386 struct and union parameter alignment"Pengfei Wang2019-05-311-11/+2
| | | | | | | | | | This reverts commit d61cb749f4ac2c90244906d756e80a5c4a7ffa89 (SVN: 361934). According to James suggestion, revert this change. Please ref: https://reviews.llvm.org/D60748 llvm-svn: 362186
* [X86] Fix i386 struct and union parameter alignmentPengfei Wang2019-05-291-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to i386 System V ABI 2.1: Structures and unions assume the alignment of their most strictly aligned component. But current implementation always takes them as 4-byte aligned which will result in incorrect code, e.g: 1 #include <immintrin.h> 2 typedef union { 3 int d[4]; 4 __m128 m; 5 } M128; 6 extern void foo(int, ...); 7 void test(void) 8 { 9 M128 a; 10 foo(1, a); 11 foo(1, a.m); 12 } The first call (line 10) takes the second arg as 4-byte aligned while the second call (line 11) takes the second arg as 16-byte aligned. There is oxymoron for the alignment of the 2 calls because they should be the same. This patch fixes the bug by following i386 System V ABI and apply it to Linux only since other System V OS (e.g Darwin, PS4 and FreeBSD) don't want to spend any effort dealing with the ramifications of ABI breaks at present. Patch by Wei Xiao (wxiao3) Differential Revision: https://reviews.llvm.org/D60748 llvm-svn: 361934
* [ARM][AArch64] Fix incorrect handling of alignment in va_arg code generationJohn Brawn2019-05-221-14/+14
| | | | | | | | | | | | | Overaligned and underaligned types (i.e. types where the alignment has been increased or decreased using the aligned and packed attributes) weren't being correctly handled in all cases, as the unadjusted alignment should be used. This patch also adjusts getTypeUnadjustedAlign to correctly handle typedefs of non-aggregate types, which it appears it never had to handle before. Differential Revision: https://reviews.llvm.org/D62152 llvm-svn: 361372
* [ELF] Implement Dependent Libraries FeatureBen Dunbobbin2019-05-171-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements a limited form of autolinking primarily designed to allow either the --dependent-library compiler option, or "comment lib" pragmas ( https://docs.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?view=vs-2017) in C/C++ e.g. #pragma comment(lib, "foo"), to cause an ELF linker to automatically add the specified library to the link when processing the input file generated by the compiler. Currently this extension is unique to LLVM and LLD. However, care has been taken to design this feature so that it could be supported by other ELF linkers. The design goals were to provide: - A simple linking model for developers to reason about. - The ability to to override autolinking from the linker command line. - Source code compatibility, where possible, with "comment lib" pragmas in other environments (MSVC in particular). Dependent library support is implemented differently for ELF platforms than on the other platforms. Primarily this difference is that on ELF we pass the dependent library specifiers directly to the linker without manipulating them. This is in contrast to other platforms where they are mapped to a specific linker option by the compiler. This difference is a result of the greater variety of ELF linkers and the fact that ELF linkers tend to handle libraries in a more complicated fashion than on other platforms. This forces us to defer handling the specifiers to the linker. In order to achieve a level of source code compatibility with other platforms we have restricted this feature to work with libraries that meet the following "reasonable" requirements: 1. There are no competing defined symbols in a given set of libraries, or if they exist, the program owner doesn't care which is linked to their program. 2. There may be circular dependencies between libraries. The binary representation is a mergeable string section (SHF_MERGE, SHF_STRINGS), called .deplibs, with custom type SHT_LLVM_DEPENDENT_LIBRARIES (0x6fff4c04). The compiler forms this section by concatenating the arguments of the "comment lib" pragmas and --dependent-library options in the order they are encountered. Partial (-r, -Ur) links are handled by concatenating .deplibs sections with the normal mergeable string section rules. As an example, #pragma comment(lib, "foo") would result in: .section ".deplibs","MS",@llvm_dependent_libraries,1 .asciz "foo" For LTO, equivalent information to the contents of a the .deplibs section can be retrieved by the LLD for bitcode input files. LLD processes the dependent library specifiers in the following way: 1. Dependent libraries which are found from the specifiers in .deplibs sections of relocatable object files are added when the linker decides to include that file (which could itself be in a library) in the link. Dependent libraries behave as if they were appended to the command line after all other options. As a consequence the set of dependent libraries are searched last to resolve symbols. 2. It is an error if a file cannot be found for a given specifier. 3. Any command line options in effect at the end of the command line parsing apply to the dependent libraries, e.g. --whole-archive. 4. The linker tries to add a library or relocatable object file from each of the strings in a .deplibs section by; first, handling the string as if it was specified on the command line; second, by looking for the string in each of the library search paths in turn; third, by looking for a lib<string>.a or lib<string>.so (depending on the current mode of the linker) in each of the library search paths. 5. A new command line option --no-dependent-libraries tells LLD to ignore the dependent libraries. Rationale for the above points: 1. Adding the dependent libraries last makes the process simple to understand from a developers perspective. All linkers are able to implement this scheme. 2. Error-ing for libraries that are not found seems like better behavior than failing the link during symbol resolution. 3. It seems useful for the user to be able to apply command line options which will affect all of the dependent libraries. There is a potential problem of surprise for developers, who might not realize that these options would apply to these "invisible" input files; however, despite the potential for surprise, this is easy for developers to reason about and gives developers the control that they may require. 4. This algorithm takes into account all of the different ways that ELF linkers find input files. The different search methods are tried by the linker in most obvious to least obvious order. 5. I considered adding finer grained control over which dependent libraries were ignored (e.g. MSVC has /nodefaultlib:<library>); however, I concluded that this is not necessary: if finer control is required developers can fall back to using the command line directly. RFC thread: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html. Differential Revision: https://reviews.llvm.org/D60274 llvm-svn: 360984
* [HIP] Fix visibility of `__constant__` variables.Michael Liao2019-04-261-1/+2
| | | | | | | | | | | | | | | | Summary: - `__constant__` variables should not be `hidden` as the linker may turn them into `LOCAL` symbols. Reviewers: yaxunl Subscribers: jvesely, nhaehnle, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61194 llvm-svn: 359344
* AMDGPU: Add support for cross address space synchronization scopes (clang)Konstantin Zhuravlyov2019-03-251-9/+24
| | | | | | Differential Revision: https://reviews.llvm.org/D59494 llvm-svn: 356947
* [ARM] Fix bug 39982 - pcs("aapcs-vfp") is not consistentCarey Williams2019-03-221-16/+36
| | | | | | | | | | Correctly handle homogeneous aggregates when a function's ABI is specified via the pcs attribute. Bug: https://bugs.llvm.org/show_bug.cgi?id=39982 Differential Revision: https://reviews.llvm.org/D59094 llvm-svn: 356776
* [CodeGen][ObjC] Annotate calls to objc_retainAutoreleasedReturnValueAkira Hatanaka2019-03-211-0/+6
| | | | | | | | | | | | | with notail on x86-64. On x86-64, the epilogue code inserted before the tail jump blocks the autoreleased return optimization. rdar://problem/38675807 Differential Revision: https://reviews.llvm.org/D59656 llvm-svn: 356705
* AMDGPU: Fix the mapping of sub group sync scopeKonstantin Zhuravlyov2019-03-061-1/+1
| | | | | | | | Map memory_scope_sub_group to "wavefront" sync scope Differential Revision: https://reviews.llvm.org/D58847 llvm-svn: 355549
* [OPENMP]Delay emission of the error for unsupported types.Alexey Bataev2019-02-271-0/+46
| | | | | | | If the type is unsupported on the device side, it still must be emitted, but we should emit errors for operations with such types. llvm-svn: 355027
* [AMDGPU] Allow using integral non-type template parametersMichael Liao2019-02-261-4/+16
| | | | | | | | | | | | | | | | | | | Summary: - Allow using integral non-type template parameters in the following attributes __attribute__((amdgpu_flat_work_group_size(<min>, <max>))) __attribute__((amdgpu_waves_per_eu(<min>[, <max>]))) Reviewers: kzhuravl, yaxunl Subscribers: jvesely, wdng, nhaehnle, dstuttard, tpr, t-tye, jdoerfert, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D58623 llvm-svn: 354909
* [AMDGPU] Require at least protected visibility for certain symbolsScott Linder2019-02-121-0/+15
| | | | | | | | | This allows the global visibility controls to be restrictive while still populating the dynamic symbol table where required. Differential Revision: https://reviews.llvm.org/D56871 llvm-svn: 353870
* [opaque pointer types] Cleanup CGBuilder's Create*GEP.James Y Knight2019-02-091-50/+25
| | | | | | | | | | | | | | The various EltSize, Offset, DataLayout, and StructLayout arguments are all computable from the Address's element type and the DataLayout which the CGBuilder already has access to. After having previously asserted that the computed values are the same as those passed in, now remove the redundant arguments from CGBuilder's Create*GEP functions. Differential Revision: https://reviews.llvm.org/D57767 llvm-svn: 353629
* [opaque pointer types] Cleanup CGBuilder's Create*GEP.James Y Knight2019-02-081-2/+3
| | | | | | | | | | | | | | | | | | | | | | | Some of these functions take some extraneous arguments, e.g. EltSize, Offset, which are computable from the Type and DataLayout. Add some asserts to ensure that the computed values are consistent with the passed-in values, in preparation for eliminating the extraneous arguments. This also asserts that the Type is an Array for the calls named "Array" and a Struct for the calls named "Struct". Then, correct a couple of errors: 1. Using CreateStructGEP on an array type. (this causes the majority of the test differences, as struct GEPs are created with i32 indices, while array GEPs are created with i64 indices) 2. Passing the wrong Offset to CreateStructGEP in TargetInfo.cpp on x86-64 NACL (which uses 32-bit pointers). Differential Revision: https://reviews.llvm.org/D57766 llvm-svn: 353529
* Minor cleanup: remove CGBuild::CreateConst*ByteGEP overloads taking a Value*.James Y Knight2019-02-051-10/+7
| | | | llvm-svn: 353197
* [WebAssembly] Add an import_field function attributeDan Gohman2019-02-011-1/+7
| | | | | | | | | | | | | | | | | | | | | | | This is similar to import_module, but sets the import field name instead. By default, the import field name is the same as the C/asm/.o symbol name. However, there are situations where it's useful to have it be different. For example, suppose I have a wasm API with a module named "pwsix" and a field named "read". There's no risk of namespace collisions with user code at the wasm level because the generic name "read" is qualified by the module name "pwsix". However in the C/asm/.o namespaces, the module name is not used, so if I have a global function named "read", it is intruding on the user's namespace. With the import_field module, I can declare my function (in libc) to be "__read", and then set the wasm import module to be "pwsix" and the wasm import field to be "read". So at the C/asm/.o levels, my symbol is outside the user namespace. Differential Revision: https://reviews.llvm.org/D57602 llvm-svn: 352930
* [WebAssembly] Add an import_module function attributeDan Gohman2019-01-241-0/+10
| | | | | | | | | This adds a C/C++ attribute which corresponds to the LLVM IR wasm-import-module attribute. It allows code to specify an explicit import module. Differential Revision: https://reviews.llvm.org/D57160 llvm-svn: 352106
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [MSP430] Improve support of 'interrupt' attributeAnton Korobeynikov2019-01-161-12/+10
| | | | | | | | | | | | * Accept as an argument constants in range 0..63 (aligned with TI headers and linker scripts provided with TI GCC toolchain). * Emit function attribute 'interrupt'='xx' instead of aliases (used in the backend to create a section for particular interrupt vector). * Add more diagnostics. Patch by Kristina Bessonova! Differential Revision: https://reviews.llvm.org/D56663 llvm-svn: 351344
* Adopt SwiftABIInfo for WebAssembly.Daniel Dunbar2019-01-031-6/+17
| | | | | | | | | | | | | | | | | Summary: - This adopts SwiftABIInfo as the base class for WebAssemblyABIInfo, which is in keeping with what is done for other targets for which Swift is supported. - This is a minimal patch to unblock exploration of WASM support for Swift (https://bugs.swift.org/browse/SR-9307) Reviewers: rjmccall, sunfish Reviewed By: rjmccall Subscribers: ahti, dschuff, sbc100, jgravelle-google, aheejin, cfe-commits Differential Revision: https://reviews.llvm.org/D56188 llvm-svn: 350372
* Move CodeGenOptions from Frontend to BasicRichard Trieu2018-12-111-1/+1
| | | | | | Basic uses CodeGenOptions and should not depend on Frontend. llvm-svn: 348827
* [clang][ARC] Add ARCTargetInfoTatyana Krasnukha2018-11-271-0/+133
| | | | | | | | Based-on-patch-by: Pete Couperus <petecoup@synopsys.com> Differential Revision: https://reviews.llvm.org/D53100 llvm-svn: 347699
* Re-land r345676 "[Win64] Handle passing i128 by value"Reid Kleckner2018-10-311-11/+33
| | | | | | | Fix the unintended switch/case fallthrough to avoid changing long double behavior. llvm-svn: 345748
* Revert r345676 due to test failure.Richard Trieu2018-10-311-33/+11
| | | | | | This was causing CodeGen/mingw-long-double.c to start failing. llvm-svn: 345691
* [Win64] Handle passing i128 by valueReid Kleckner2018-10-301-11/+32
| | | | | | | | | | | | For arguments, pass it indirectly, since the ABI doc says pretty clearly that arguments larger than 8 bytes are passed indirectly. This makes va_list handling easier, anyway. When returning, GCC returns in XMM0, and we match them. Fixes PR39492. llvm-svn: 345676
* [AArch64] Support Windows stack probe command-line arguments.Eli Friedman2018-10-261-0/+11
| | | | | | | | | | | Adds support for -mno-stack-arg-probe and -mstack-probe-size. (Not really happy copy-pasting code, but that's what we do for all the other Windows targets.) Differential Revision: https://reviews.llvm.org/D53617 llvm-svn: 345354
* [AArch64] Branch Protection and Return Address Signing B Key SupportLuke Cheeseman2018-10-251-6/+14
| | | | | | | | | | | - Add support for -mbranch-protection=<type>[+<type>]* where - <type> ::= [standard, none, bti, pac-ret[+b-key,+leaf]*] - The protection emits relevant function attributes - sign-return-address=<scope> - sign-return-address-key=<key> - branch-protection llvm-svn: 345273
* [MinGW] Fix passing a sanitizer lib name as dependent libMartin Storsjo2018-10-101-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D52990 llvm-svn: 344125
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-261-2/+2
| | | | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: rsmith, #clang, dblaikie Reviewed By: rsmith, #clang Subscribers: mgrang, arphaman, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D52576 llvm-svn: 343147
* [CodeGen][ARM] Coerce FP16 vectors to integer vectors when neededMikhail Maltsev2018-09-121-32/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On targets that do not support FP16 natively LLVM currently legalizes vectors of FP16 values by scalarizing them and promoting to FP32. This causes problems for the following code: void foo(int, ...); typedef __attribute__((neon_vector_type(4))) __fp16 float16x4_t; void bar(float16x4_t x) { foo(42, x); } According to the AAPCS (appendix A.2) float16x4_t is a containerized vector fundamental type, so 'foo' expects that the 4 16-bit FP values are packed into 2 32-bit registers, but instead bar promotes them to 4 single precision values. Since we already handle scalar FP16 values in the frontend by bitcasting them to/from integers, this patch adds similar handling for vector types and homogeneous FP16 vector aggregates. One existing test required some adjustments because we now generate more bitcasts (so the patch changes the test to target a machine with native FP16 support). Reviewers: eli.friedman, olista01, SjoerdMeijer, javed.absar, efriedma Reviewed By: javed.absar, efriedma Subscribers: efriedma, kristof.beyls, cfe-commits, chrib Differential Revision: https://reviews.llvm.org/D50507 llvm-svn: 342034
* [AArch64] - return address signingLuke Cheeseman2018-08-171-0/+17
| | | | | | | | | | | | | | - Add a command line options -msign-return-address to enable return address signing - Armv8.3a added instructions to sign the return address to help mitigate against ROP attacks - This patch adds command line options to generate function attributes that signal to the back whether return address signing instructions should be added Differential revision: https://reviews.llvm.org/D49793 llvm-svn: 340019
* Remove trailing spaceFangrui Song2018-07-301-12/+12
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [ARM, AArch64]: Use unadjusted alignment when passing composites as argumentsMomchil Velikov2018-07-301-5/+14
| | | | | | | | | | | | | | | | | | The "Procedure Call Procedure Call Standard for the ARM® Architecture" (https://static.docs.arm.com/ihi0042/f/IHI0042F_aapcs.pdf), specifies that composite types are passed according to their "natural alignment", i.e. the alignment before alignment adjustment on the entire composite is applied. The same applies for AArch64 ABI. Clang, however, used the adjusted alignment. GCC already implements the ABI correctly. With this patch Clang becomes compatible with GCC and passes such arguments in accordance with AAPCS. Differential Revision: https://reviews.llvm.org/D46013 llvm-svn: 338279
* [mips64][clang] Provide the signext attribute for i32 return valuesStefan Maksimovic2018-07-301-2/+8
| | | | | | | | Additional info: see r338019. Differential Revision: https://reviews.llvm.org/D49289 llvm-svn: 338239
* [RISCV] Add support for interrupt attributeAna Pazos2018-07-261-0/+21
| | | | | | | | | | | | | | | | | | | Summary: Clang supports the GNU style ``__attribute__((interrupt))`` attribute on RISCV targets. Permissible values for this parameter are user, supervisor, and machine. If there is no parameter, then it defaults to machine. Reference: https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Function-Attributes.html Based on initial patch by Zhaoshi Zheng. Reviewers: asb, aaron.ballman Reviewed By: asb, aaron.ballman Subscribers: rkruppe, the_o, aaron.ballman, MartinMosbeck, brucehoult, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang, rogfer01, cfe-commits Differential Revision: https://reviews.llvm.org/D48412 llvm-svn: 338045
* [Power9] Update fp128 as a valid homogenous aggregate base typeLei Huang2018-07-051-4/+9
| | | | | | | | | Update clang to treat fp128 as a valid base type for homogeneous aggregate passing and returning. Differential Revision: https://reviews.llvm.org/D48044 llvm-svn: 336308
OpenPOWER on IntegriCloud