summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/TargetInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [mips] Promote all integral/enumeration types to the GPR widthDaniel Sanders2014-10-241-1/+2
| | | | | | | | | | | | | | | | | | Summary: Ensure all integral/enumeration types are appropriately annotated with signext/zeroext. In particular, i32 now has these attributes when using the N32/N64 ABI. This paves the way for accurately representing the way the N32/N64 ABI's promotes integer arguments to i64. Reviewers: atanasyan Reviewed By: atanasyan Subscribers: cfe-commits, theraven Differential Revision: http://reviews.llvm.org/D5961 llvm-svn: 220563
* CodeGen: Update for LLVM API changeDavid Majnemer2014-10-201-1/+1
| | | | | | | Callers of DataLayout::RoundUpAlignment should switch to RoundUpToAlignment. llvm-svn: 220188
* Add getOpenMPSimdDefaultAlignment for PowerPCHal Finkel2014-10-031-0/+12
| | | | | | | | | | | | When the aligned clause of an OpenMP simd pragma is not provided with an explicit alignment, a target-dependent default must be used. This adds such a default of PPC targets. This will become slightly more complicated when BG/Q support is added (because then it will depend on the type). For now, 16 is a correct value for all systems, and covers Altivec and VSX vectors. llvm-svn: 218994
* [x32/NaCl] Check if method pointers straddle an eightbyte to classify HiJan Wen Voung2014-10-021-3/+18
| | | | | | | | | | | | | | | | | | | | Summary: Currently, with struct my_struct { int x; method_ptr y; }; a call to foo(my_struct s) may end up dropping the last 4 bytes of the method pointer for x86_64 NaCl and x32. When checking Has64BitPointers, also check if the method pointer straddles an eightbyte boundary and classify Hi as well as Lo if needed. Test Plan: test/CodeGenCXX/x86_64-arguments-nacl-x32.cpp Reviewers: dschuff, pavel.v.chupin Subscribers: jfb Differential Revision: http://reviews.llvm.org/D5555 llvm-svn: 218889
* [OPENMP] Codegen of the ‘aligned’ clause for the ‘omp simd’ directive.Alexander Musman2014-09-301-10/+25
| | | | | | Differential Revision: http://reviews.llvm.org/D5499 llvm-svn: 218660
* Introduce CGFunctionInfo::getNumRequiredArgs(). NFC.Alexey Samsonov2014-09-291-17/+9
| | | | | | Save the callers from necessity to special-case on variadic functions. llvm-svn: 218625
* Revert "Don't use comdats for initializers on platforms that don't support it"Reid Kleckner2014-09-231-8/+0
| | | | | | | | | On further investigation, COMDATs should work with .ctors, and the issue I was hitting probably reproduces with .init_array. This reverts commit r218287. llvm-svn: 218313
* Don't use comdats for initializers on platforms that don't support itReid Kleckner2014-09-231-0/+8
| | | | | | | | | In particular, pre-.init_array ELF uses the .ctors section mechanism. MinGW COFF also uses .ctors, now that I think about it. Therefore, restrict this optimization to the two platforms that are currently known to work: ELF with .init_array and COFF with .CRT$XCU. llvm-svn: 218287
* [mips] Correct alignment of vectors passed in varargs for the O32 ABI.Daniel Sanders2014-09-221-1/+2
| | | | | | | | | | | | | | | | | | | Summary: Vectors are normally 16-byte aligned, however the O32 ABI enforces a maximum alignment of 8-bytes since the base of the stack is 8-byte aligned. Previously, this was enforced on the caller side, but not on the callee side. This fixes the output of OpenCL's printf when given vectors. Reviewers: atanasyan Reviewed By: atanasyan Subscribers: llvm-commits, pekka.jaaskelainen Differential Revision: http://reviews.llvm.org/D5433 llvm-svn: 218248
* Don't use the third field of llvm.global_ctors for MachO.Rafael Espindola2014-09-191-0/+8
| | | | | | | | | | The field is defined as: If the third field is present, non-null, and points to a global variable or function, the initializer function will only run if the associated data from the current module is not discarded. And without COMDATs we can't implement that. llvm-svn: 218097
* Revert "Put more stuff in the comdat used for variables with static init."Rafael Espindola2014-09-191-8/+0
| | | | | | | This reverts commit r218089. It looks like it was causing issues on COFF. llvm-svn: 218094
* Put more stuff in the comdat used for variables with static init.Rafael Espindola2014-09-181-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang can already handle ------------------------------------------- struct S { static const int x; }; template<typename T> struct U { static const int k; }; template<typename T> const int U<T>::k = T::x; const int S::x = 42; extern const int *f(); const int *g() { return &U<S>::k; } int main() { return *f() + U<S>::k; } const int *f() { return &U<S>::k; } ------------------------------------------- since r217264 which puts the .inint_array section in the same COMDAT as the variable. This patch allows the linker to more easily delete some dead code and data by putting the guard variable and init function in the same COMDAT. llvm-svn: 218089
* MS inline asm: Allow __asm blocks to set a return valueReid Kleckner2014-09-041-0/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | If control falls off the end of a function after an __asm block, MSVC assumes that the inline assembly filled the EAX and possibly EDX registers with an appropriate return value. This functionality is used in inline functions returning 64-bit integers in system headers, so we need some amount of compatibility. This is implemented in Clang by adding extra output constraints to every inline asm block, and storing the resulting output registers into the return value slot. If we see an asm block somewhere in the function body, we emit a normal epilogue instead of marking the end of the function with a return type unreachable. Normal returns in functions not using this functionality will overwrite the return value slot, and in most cases LLVM should be able to eliminate the dead stores. Fixes PR17201. Reviewed By: majnemer Differential Revision: http://reviews.llvm.org/D5177 llvm-svn: 217187
* Fix double full-stop that was accidentally added in r217160.Daniel Sanders2014-09-041-1/+1
| | | | llvm-svn: 217161
* [mips] Mark aggregates returned in registers with the 'inreg' attribute.Daniel Sanders2014-09-041-6/+9
| | | | | | | | | | | | | | | | | | Summary: This allows us to easily find them in the backend after the aggregates have been lowered to other types. This is important on big-endian targets using the N32/N64 ABI's since these ABI's must shift small structures into the upper bits of the register. Reviewers: atanasyan Reviewed By: atanasyan Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D5005 llvm-svn: 217160
* [mips] Zero-sized structs cannot be ignored in ↵Daniel Sanders2014-09-041-1/+6
| | | | | | | | | | | | | | | | | | | | | | | MipsABIInfo::classifyReturnType() for O32 Summary: They are returned indirectly which causes the other arguments to move to the next argument slot. With this, utils/ABITest does not discover any failing cases in the first 500 attempts on big/little endian for O32. Previously some of these failed. Also tested N32/N64 little endian (big endian has other known issues) with no issues. Reviewers: atanasyan Reviewed By: atanasyan Subscribers: atanasyan, cfe-commits Differential Revision: http://reviews.llvm.org/D4811 llvm-svn: 217147
* Allow __fp16 as a function arg or return type for AArch64Oliver Stannard2014-08-271-17/+29
| | | | | | | | | | | ACLE 2.0 allows __fp16 to be used as a function argument or return type. This enables this for AArch64. This also fixes an existing bug that causes clang to not allow homogeneous floating-point aggregates with a base type of __fp16. This is valid for AAPCS64, but not for AAPCS-VFP. llvm-svn: 216558
* Move some ARM-specific code from CGCall.cpp to TargetInfo.cppOliver Stannard2014-08-271-19/+34
| | | | | | | | | This tidies up some ARM-specific code added by r208417 to move it out of the target-independent parts of clang into TargetInfo.cpp. This also has the advantage that we can now flatten struct arguments to variadic AAPCS functions. llvm-svn: 216535
* Re-apply r216491 (Win64 ABI shouldn't extend integer type arguments.)Julien Lerouge2014-08-271-1/+4
| | | | | | | | | This time though, preserve the extension for bool types since that's compatible with what MSVC expects. See http://reviews.llvm.org/D4380 llvm-svn: 216507
* Revert 216491, it breaks CodeGenCXX/microsoft-abi-member-pointers.cppJulien Lerouge2014-08-261-0/+3
| | | | llvm-svn: 216496
* Win64 ABI shouldn't extend integer type arguments.Julien Lerouge2014-08-261-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: MSVC doesn't extend integer types smaller than 64bit, so to preserve binary compatibility, clang shouldn't either. For example, the following C code built with MSVC: unsigned test(unsigned v); unsigned foobar(unsigned short); int main() { return test(0xffffffff) + foobar(28); } Produces the following: 0000000000000004: B9 FF FF FF FF mov ecx,0FFFFFFFFh 0000000000000009: E8 00 00 00 00 call test 000000000000000E: 89 44 24 20 mov dword ptr [rsp+20h],eax 0000000000000012: 66 B9 1C 00 mov cx,1Ch 0000000000000016: E8 00 00 00 00 call foobar And as you can see, when setting up the call to foobar, only cx is overwritten. If foobar is compiled with clang, then the zero extension added by clang means the rest of the register, which contains garbage, could be used. For example if foobar is: unsigned foobar(unsigned short v) { return v; } Compiled with clang -fomit-frame-pointer -O3 gives the following assembly: foobar: 0000000000000000: 89 C8 mov eax,ecx 0000000000000002: C3 ret And that function would return garbage because the 16 most significant bits of ecx still contain garbage from the first call. With this change, the code for that function is now: foobar: 0000000000000000: 0F B7 C1 movzx eax,cx 0000000000000003: C3 ret Reviewers: chapuni, rnk Reviewed By: rnk Subscribers: majnemer, cfe-commits Differential Revision: http://reviews.llvm.org/D4380 llvm-svn: 216491
* Range'ify some for loops over RecordDecl::fields()Hans Wennborg2014-08-211-8/+7
| | | | | | No functionality change. llvm-svn: 216183
* Delete support for AuroraUX.Rafael Espindola2014-08-141-1/+0
| | | | | | auroraux.org is not resolving. llvm-svn: 215644
* Revert r214497: [mips] Defer va_arg expansion to the backend.Daniel Sanders2014-08-011-1/+33
| | | | | | | | It appears that the backend does not handle all cases that were handled by clang. In particular, it does not handle structs as used in SingleSource/UnitTests/2003-05-07-VarArgs. llvm-svn: 214512
* [mips] Defer va_arg expansion to the backend.Daniel Sanders2014-08-011-33/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch causes clang to emit va_arg instructions to the backend instead of expanding them into an implementation itself. The backend already implements va_arg since this is necessary for NaCl so this patch is removing redundant code. Together with the llvm patch (D4556) that accounts for the effect of endianness on the expansion of va_arg, this fixes PR19612. Depends on D4556 Reviewers: sstankovic, dsanders Reviewed By: dsanders Subscribers: rnk, cfe-commits Differential Revision: http://reviews.llvm.org/D4742 llvm-svn: 214497
* [PowerPC] Support ELFv1/ELFv2 ABI selection via -mabi= optionUlrich Weigand2014-07-281-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently hard-coded via the target triple: powerpc64-linux is always ELFv1, while powerpc64le-linux is always ELFv2. These are of course the most common scenarios, but in principle it is possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on little-endian systems (and GCC does support that), and there are some special use cases for that (e.g. certain Linux kernel versions could only be built using ELFv1 on LE). This patch implements the Clang side of supporting this, based on the LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2 select the desired ABI if present. (If not, Clang uses the same default rules as now.) Specifically, the patch implements the following changes based on the presence of the -mabi= option: In the driver: - Pass the appropiate -target-abi flag to the back-end - Select the correct dynamic loader version (/lib64/ld64.so.[12]) In the preprocessor: - Define _CALL_ELF to the appropriate value (1 or 2) In the compiler back-end: - Select the correct ABI in TargetInfo.cpp - Select the desired ABI for LLVM via feature (elfv1/elfv2) llvm-svn: 214074
* MS ABI: Ensure 'this' is first for byval+sret methodsReid Kleckner2014-07-261-21/+34
| | | | | | | | | Previously we were building up the inalloca struct in the usual pattern of return type followed by arguments. However, on Windows, 'this' always precedes the 'sret' parameter, so we need to insert it into the struct first as a special case. llvm-svn: 213990
* AArch64: update Clang for merged arm64/aarch64 triples.Tim Northover2014-07-231-3/+1
| | | | | | | | | | | | | | The main subtlety here is that the Darwin tools still need to be given "-arch arm64" rather than "-arch aarch64". Fortunately this already goes via a custom function to handle weird edge-cases in other architectures, and it tested. I removed a few arm64_be tests because that really isn't an interesting thing to worry about. No-one using big-endian is also referring to the target as arm64 (at least as far as toolchains go). Mostly they date from when arm64 was a separate target and we *did* need a parallel name simply to test it at all. Now aarch64_be is sufficient. llvm-svn: 213744
* [PowerPC] Optimize passing certain aggregates by valueUlrich Weigand2014-07-211-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | In addition to enabling ELFv2 homogeneous aggregate handling, LLVM support to pass array types directly also enables a performance enhancement. We can now pass (non-homogeneous) aggregates that fit fully in registers as direct integer arrays, using an element type to encode the alignment requirement (that would otherwise go to the "byval align" field). This is preferable since "byval" forces the back-end to write the aggregate out to the stack, even if it could be passed fully in registers. This is particularly annoying on ELFv2, if there is no parameter save area available, since we then need to allocate space on the callee's stack just to hold those aggregates. Note that to implement this optimization, this patch does not attempt to fully anticipate register allocation rules as (defined in the ABI and) implemented in the back-end. Instead, the patch is simply passing *any* aggregate passed by value using the array mechanism if its size is up to 64 bytes. This means that some of those will end up being passed in stack slots anyway, but the generated code shouldn't be any worse either. (*Large* aggregates remain passed using "byval" to enable optimized copying via memcpy etc.) llvm-svn: 213495
* [PowerPC] Support the ELFv2 ABIUlrich Weigand2014-07-211-9/+169
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements clang support for the PowerPC ELFv2 ABI. Together with a series of companion patches in LLVM, this makes clang/LLVM fully usable on powerpc64le-linux. Most of the ELFv2 ABI changes are fully implemented on the LLVM side. On the clang side, we only need to implement some changes in how aggregate types are passed by value. Specifically, we need to: - pass (and return) "homogeneous" floating-point or vector aggregates in FPRs and VRs (this is similar to the ARM homogeneous aggregate ABI) - return aggregates of up to 16 bytes in one or two GPRs The second piece is trivial to implement in any case. To implement the first piece, this patch makes use of infrastructure recently enabled in the LLVM PowerPC back-end to support passing array types directly, where the array element type encodes properties needed to handle homogeneous aggregates correctly. Specifically, the array element type encodes: - whether the parameter should be passed in FPRs, VRs, or just GPRs/stack slots (for float / vector / integer element types, respectively) - what the alignment requirements of the parameter are when passed in GPRs/stack slots (8 for float / 16 for vector / the element type size for integer element types) -- this corresponds to the "byval align" field With this support in place, the clang part simply needs to *detect* whether an aggregate type implements a float / vector homogeneous aggregate as defined by the ELFv2 ABI, and if so, pass/return it as array type using the appropriate float / vector element type. llvm-svn: 213494
* [ARM] Fix AAPCS regression caused by r211898Oliver Stannard2014-07-181-1/+5
| | | | | | | | | | | | | r211898 introduced a regression where a large struct, which would normally be passed ByVal, was causing padding to be inserted to prevent the backend from using some GPRs, in order to follow the AAPCS. However, the type of the argument was not being set correctly, so the backend cannot align 8-byte aligned struct types on the stack. The fix is to not insert the padding arguments when the argument is being passed ByVal. llvm-svn: 213359
* [PowerPC] ABI support for aligned by-value aggregatesUlrich Weigand2014-07-101-1/+50
| | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for respecting the ABI and type alignment of aggregates passed by value. Currently, all aggregates are aligned at 8 bytes in the parameter save area. This is incorrect for two reasons: - Aggregates that need alignment of 16 bytes or more should be aligned at 16 bytes in the parameter save area. This is implemented by using an appropriate "byval align" attribute in the IR. - Aggregates that need alignment beyond 16 bytes need to be dynamically realigned by the caller. This is implemented by setting the Realign flag of the ABIArgInfo::getIndirect call. In addition, when expanding a va_arg call accessing a type that is aligned at 16 bytes in the argument save area (either one of the aggregate types as above, or a vector type which is already aligned at 16 bytes), code needs to align the va_list pointer accordingly. Reviewed by Hal Finkel. llvm-svn: 212743
* [PowerPC] ABI support for non-Altivec vector typesUlrich Weigand2014-07-101-1/+26
| | | | | | | | | | | | | | | | | | | | | This patch adds support for passing arguments of non-Altivec vector type (i.e. defined via attribute ((vector_size (...)))) on powerpc64-linux. While such types are not mentioned in the formal ABI document, this patch implements a calling convention compatible with GCC: - Vectors of size < 16 bytes are passed in a GPR - Vectors of size > 16 bytes are passed via reference Note that vector types with a number of elements that is not a power of 2 are not supported by GCC, so there is no pre-existing ABI to follow. We choose to pass those (of size < 16) as if widened to the next power of two, so they might end up in a vector register or in a GPR. (Sizes > 16 are always passed via reference as well.) Reviewed by Hal Finkel. llvm-svn: 212734
* MS ABI: Fix __fastcall methods that return structsReid Kleckner2014-07-101-1/+9
| | | | | | | | | The sret paramater consumes the register after the implicit 'this' parameter, as with other calling conventions. Fixes PR20278, which turned out to be very easy. llvm-svn: 212669
* Fix 'source-level' hyphenationsAlp Toker2014-07-091-1/+1
| | | | llvm-svn: 212621
* Move misplaced x86_32 ABI codeRichard Sandiford2014-07-081-38/+38
| | | | | | | | | | r184166 added an X86_32 function in the middle of the SystemZ code. The SystemZ port had been added only a couple of weeks earlier and the original patch probably predated that. No behavioral change intended. llvm-svn: 212524
* ARMEB: Fix function result return for composite typesChristian Pirker2014-07-031-0/+4
| | | | | | Reviewed at http://reviews.llvm.org/D4364 llvm-svn: 212261
* [ARM] Fix AAPCS non-compliance caused by very large structsOliver Stannard2014-06-271-3/+6
| | | | | | | | | | | | | | This is a fix to the code in clang which inserts padding arguments to ensure that the ARM backend can emit AAPCS-VFP compliant code. This code needs to track the number of registers which have been allocated in order to do this. When passing a very large struct (>64 bytes) by value, clang emits IR which takes a pointer to the struct, but the backend converts this back to passing the struct in registers and on the stack. The bug was that this was being considered by clang to only use one register, meaning that there were situations in which padding arguments were incorrectly emitted by clang. llvm-svn: 211898
* Correctly Load Mixed FP-GP Variadic Arguments for x86-64.Rafael Espindola2014-06-241-2/+2
| | | | | | | | | | | | | | | | | | | | According to the x86-64 ABI, structures with both floating point and integer members are split between floating-point and general purpose registers, and consecutive 32-bit floats can be packed into a single floating point register. In the case of variadic functions these are stored to memory and the position recorded in the va_list. This was already correctly implemented in llvm.va_start. The problem is that the code in clang for implementing va_arg was reading floating point registers from the wrong location. Patch by Thomas Jablin. Fixes PR20018. llvm-svn: 211626
* [PowerPC] Fix small argument stack slot offset for LEUlrich Weigand2014-06-201-3/+7
| | | | | | | | | | | | | | | | | When small arguments (structures < 8 bytes or "float") are passed in a stack slot in the ppc64 SVR4 ABI, they must reside in the least significant part of that slot. On BE, this means that an offset needs to be added to the stack address of the parameter, but on LE, the least significant part of the slot has the same address as the slot itself. For the most part, this is handled in the LLVM back-end, where I just fixed the LE case in commit r211368. However, there is one piece of the clang front-end that is also aware of these stack-slot offsets: PPC64_SVR4_ABIInfo::EmitVAArg. This patch updates that routine to take endianness into account. llvm-svn: 211370
* StringRefize TargetInfo::getABI()Alp Toker2014-06-071-3/+3
| | | | llvm-svn: 210402
* XCore target: Fix 'typestring' binding qualifier to the array and not the typeRobert Lytton2014-06-051-6/+12
| | | | | | Differential Revision: http://reviews.llvm.org/D3949 llvm-svn: 210250
* AArch64/ARM64: rename ARM64 components to AArch64Tim Northover2014-05-241-20/+20
| | | | | | This keeps Clang consistent with backend naming conventions. llvm-svn: 209579
* AArch64/ARM64: update Clang after AArch64 removal.Tim Northover2014-05-241-219/+2
| | | | | | | | | | | A few (mostly CodeGen) parts of Clang were tightly coupled to the AArch64 backend. Now that it's gone, they will not even compile. I've also deduplicated RUN lines in many of the AArch64 tests. This might improve "make check-all" time noticably: some of those NEON tests were monsters. llvm-svn: 209578
* [C++11] Use 'nullptr'. CodeGen edition.Craig Topper2014-05-211-40/+40
| | | | llvm-svn: 209272
* XCore target: sort typestring enum fields alphabeticallyRobert Lytton2014-05-201-16/+23
| | | | llvm-svn: 209196
* ARM: PCS non-compliance when struct is padded to avoid register/stack split, ↵Oliver Stannard2014-05-191-4/+8
| | | | | | | | | | and requires internal padding When we were padding a struct to avoid splitting it between registers and the stack, we were throwing away the type which the argument should be coerced to. llvm-svn: 209122
* Update for llvm api change.Rafael Espindola2014-05-171-2/+2
| | | | llvm-svn: 209077
* Update for llvm api change.Rafael Espindola2014-05-171-3/+2
| | | | llvm-svn: 209074
* CodeGen: remove MinGW and Cygwin legacy entriesSaleem Abdulrasool2014-05-171-2/+0
| | | | | | | | | These are now treated as environments. Remove references to these enumeration values in order to clean up the unused enumeration entries in LLVM. The target normalisation prior to tool invocation should ensure that the old values continue to function properly. llvm-svn: 209068
OpenPOWER on IntegriCloud