summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/TargetInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Implement the __builtin_call_with_static_chain GNU extension.Peter Collingbourne2014-12-121-0/+8
| | | | | | | | | | | | | | | | The extension has the following syntax: __builtin_call_with_static_chain(Call, Chain) where Call must be a function call expression and Chain must be of pointer type This extension performs a function call Call with a static chain pointer Chain passed to the callee in a designated register. This is useful for calling foreign language functions whose ABI uses static chain pointers (e.g. to implement closures). Differential Revision: http://reviews.llvm.org/D6332 llvm-svn: 224167
* IR: Update clang for Metadata/Value split in r223802Duncan P. N. Exon Smith2014-12-091-14/+19
| | | | | | Match LLVM API changes from r223802. llvm-svn: 223803
* Add attributes for AMDGPU register limits.Matt Arsenault2014-12-041-0/+42
| | | | | | | This is a performance hint that can be applied to kernels to attempt to limit the number of used registers. llvm-svn: 223384
* Fix invalid calling convention used for libcalls on ARM.Anton Korobeynikov2014-12-021-3/+6
| | | | | | | | | | | | | | | | ARM ABI specifies that all the libcalls use soft FP ABI (even hard FP binaries). These days clang emits _mulsc3 / _muldc3 calls with default (C) calling convention which would be translated into AAPCS_VFP LLVM calling and thus the result of complex multiplication will be bogus. Introduce a way for a target to specify explicitly calling convention for libcalls. Right now this is temporary correctness fix. Ultimately, we'll end with intrinsic for complex multiplication and all calling convention decisions for libcalls will be put into backend. llvm-svn: 223123
* Use nullptr to silence -Wsentinel when self-hosting on WindowsReid Kleckner2014-12-011-4/+4
| | | | | | | | | | | Richard rejected my Sema change to interpret an integer literal zero in a varargs context as a null pointer, so -Wsentinel sees an integer literal zero and fires off a warning. Only CodeGen currently knows that it promotes integer literal zeroes in this context to pointer size on Windows. I didn't want to teach -Wsentinel about that compatibility hack. Therefore, I'm migrating to C++11 nullptr. llvm-svn: 223079
* AArch64: simplify PCS mapping.Tim Northover2014-11-271-122/+30
| | | | | | | | | | | | Now that LLVM can count the registers needed to implement AAPCS rules, we don't need to duplicate that logic here. This means we can drop the explicit padding and also use more natural types in many cases (e.g. "struct { float arr[3]; }" used to end up as "[2 x double]" to avoid holes on the stack. The one wrinkle is that AAPCS va_arg was also using the register counting machinery. But the local replacement isn't too bad. llvm-svn: 222904
* Remove unnecessary environment switchReid Kleckner2014-11-241-11/+1
| | | | | | | | All supported environments on x86 Windows return structs in EAX:EDX. This removes code added in r204978 that had to get updated in r222680. We should now have the same behavior we had before r204978. llvm-svn: 222697
* CodeGen: make i686-windows-itanium more similar to msvcSaleem Abdulrasool2014-11-241-0/+1
| | | | | | | The itanium environment follows the system calling convention for structures. Pass small aggregates via registers. llvm-svn: 222680
* CodeGen: tweak struct ABI handlingSaleem Abdulrasool2014-11-231-1/+1
| | | | | | | | Cygwin and MinGW fail to conform to the underlying system's structure passing ABI. Make the check more precise to ensure that we correctly generate code for the itanium environment. llvm-svn: 222626
* Allow EmitVAArg() to promote types and use this to fix some N32/N64 vararg ↵Daniel Sanders2014-11-191-2/+10
| | | | | | | | | | | | | | | | | | | | | issues for Mips. Summary: With this patch, passing a va_list to another function and reading 10 int's from it works correctly on a big-endian target. Based on a pair of patches by David Chisnall, one of which I've reworked for the current trunk. Reviewers: theraven, atanasyan Reviewed By: theraven, atanasyan Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6248 llvm-svn: 222339
* Fix IRGen for passing transparent unionsReid Kleckner2014-11-151-0/+23
| | | | | | | | | We have had a test for this for a long time with a FIXME saying what we should be doing. This just does it. Fixes PR21573. llvm-svn: 222074
* Remove some redundant virtual specifiers on overriden functions.David Blaikie2014-11-141-1/+1
| | | | llvm-svn: 222024
* ARM ABI: simplify decisions on whether args can be expanded.Tim Northover2014-11-071-35/+21
| | | | | | | | | | | | Homogeneous aggregates on AAPCS_VFP ARM need to be passed *without* being flattened (e.g. [2 x float] rather than "float, float") for various weird ABI reasons. However, this isn't the case for anything else; further, we know at the ABIArgInfo::getDirect callsites whether this flattening is allowed. So, we can get more unified ARM code, with a simpler Clang, by just using that knowledge directly. llvm-svn: 221559
* Implement vaarg lowering for ppc32. Lowering of scalars and aggregatesRoman Divacky2014-11-031-3/+101
| | | | | | is supported. Complex numbers are not. llvm-svn: 221170
* clang/lib/CodeGen/TargetInfo.cpp: Fix a couple of warnings. ↵NAKAMURA Takumi2014-11-011-2/+2
| | | | | | [-Winconsistent-missing-override] llvm-svn: 221039
* Implement IRGen for the x86 vectorcall conventionReid Kleckner2014-10-311-25/+127
| | | | | | | | | | | | | | | The most complex aspect of the convention is the handling of homogeneous vector and floating point aggregates. Reuse the homogeneous aggregate classification code that we use on PPC64 and ARM for this. This convention also has a C mangling, and we apparently implement that in both Clang and LLVM. Reviewed By: majnemer Differential Revision: http://reviews.llvm.org/D6063 llvm-svn: 221006
* Fix ARM HVA classification of classes with non-virtual basesReid Kleckner2014-10-311-142/+108
| | | | | | | | | | | | | | | | Reuse the PPC64 HVA detection algorithm for ARM and AArch64. This is a nice code deduplication, since they are roughly identical. A few virtual method extension points are needed to understand how big an HVA can be and what element types it can have for a given architecture. Also make the record expansion code work in the presence of non-virtual bases. Reviewed By: uweigand, asl Differential Revision: http://reviews.llvm.org/D6045 llvm-svn: 220972
* Pass aggregates on the stack without splitting in NVPTX.Eli Bendersky2014-10-291-0/+4
| | | | | | | | | | | Following the NVVM IR specifications, arguments of aggregate type should be passed on the stack without splitting (byval). http://reviews.llvm.org/D6020 Patch by Jacques Pienaar. llvm-svn: 220854
* [PowerPC ABI] Bug 21398 - Consider C++ base classes in HA classificationUlrich Weigand2014-10-291-0/+16
| | | | | | | | As discussed in bug 21398, PowerPC ABI code needs to consider C++ base classes when classifying a class as homogeneous aggregate (or not) for ABI purposes. llvm-svn: 220852
* [mips] Mark aggregate arguments passed in registers with the inreg attributeDaniel Sanders2014-10-241-2/+5
| | | | | | | | | | | | | | | | | | | Summary: This allows us to easily identify them in the backend which in turn allows us to handle them correctly for big-endian targets (where they must be shifted into the upper bits of the register). Depends on D5961 Reviewers: atanasyan Reviewed By: atanasyan Subscribers: cfe-commits, theraven Differential Revision: http://reviews.llvm.org/D5962 llvm-svn: 220566
* [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
OpenPOWER on IntegriCloud