summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/TargetInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [SystemZ] Add support for z13 and its vector facilityUlrich Weigand2015-05-051-26/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for the z13 architecture type. For compatibility with GCC, a pair of options -mvx / -mno-vx can be used to selectively enable/disable use of the vector facility. When the vector facility is present, we default to the new vector ABI. This is characterized by two major differences: - Vector types are passed/returned in vector registers (except for unnamed arguments of a variable-argument list function). - Vector types are at most 8-byte aligned. The reason for the choice of 8-byte vector alignment is that the hardware is able to efficiently load vectors at 8-byte alignment, and the ABI only guarantees 8-byte alignment of the stack pointer, so requiring any higher alignment for vectors would require dynamic stack re-alignment code. However, for compatibility with old code that may use vector types, when *not* using the vector facility, the old alignment rules (vector types are naturally aligned) remain in use. These alignment rules are not only implemented at the C language level, but also at the LLVM IR level. This is done by selecting a different DataLayout string depending on whether the vector ABI is in effect or not. Based on a patch by Richard Sandiford. llvm-svn: 236531
* [cuda] Allow using integral non-type template parameters as launch_bounds ↵Artem Belevich2015-04-211-11/+15
| | | | | | | | | | | | | | | | attribute arguments. - Changed CUDALaunchBounds arguments from integers to Expr* so they can be saved in AST for instantiation. - Added support for template instantiation of launch_bounds attrubute. - Moved evaluation of launch_bounds arguments to NVPTXTargetCodeGenInfo:: SetTargetAttributes() where it can be done after template instantiation. - Added a warning on negative launch_bounds arguments. - Amended test cases. Differential Revision: http://reviews.llvm.org/D8985 llvm-svn: 235452
* Change AArch64 i128 returns to use [2 x i64] when possible.Pete Cooper2015-04-171-0/+8
| | | | | | | | | | Something like { void*, void * } would be passed to a function as a [2 x i64], but returned as an i128. This patch unifies the 2 behaviours so that we also return it as a [2 x i64]. This is better for the quality of the IR, and the size of the final LLVM binary as we tend to want to insert/extract values from these types and do so with the insert/extract instructions is less IR than shifting, truncating, and or'ing values. Reviewed by Tim Northover. llvm-svn: 235231
* Use 'override/final' instead of 'virtual' for overridden methodsAlexander Kornienko2015-04-111-6/+8
| | | | | | | | | | | | | | | | | | | | Summary: The patch is generated using clang-tidy misc-use-override check. This command was used: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \ -checks='-*,misc-use-override' -header-filter='llvm|clang' -j=32 -fix Reviewers: dblaikie Reviewed By: dblaikie Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D8926 llvm-svn: 234678
* clang-format my last commitDavid Blaikie2015-04-051-16/+21
| | | | | | (sorry, keep forgetting that) llvm-svn: 234129
* [opaque pointer type] More GEP API migrationsDavid Blaikie2015-04-051-22/+23
| | | | | | | Looks like the VTable code in particular will need some work to pass around the pointee type explicitly. llvm-svn: 234128
* [opaque pointer type] more GEP API migrationsDavid Blaikie2015-04-041-2/+4
| | | | llvm-svn: 234097
* [i386 ABI] expand small C like structs in C++, just like how we handle smallManman Ren2015-04-031-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | C structs. This comes up when we have a function that takes a struct and is defined in a C++ file and used in a C file. Before this commit, we will generate byval for C++ and will expand the struct for C, thus causing difference at IR level. We will use bitcast of function type at the callsite, which causes the inliner to not inline the function. This commit changes how we handle small C like structs at IR level, but at backend, we should generate the same argument passing before and after the commit. Note that the condition for expanding is still over conservative. We should be able to expand type that is spelled with “class” and types that are not C-like. But this commit fixes the inconsistent argument passing between C/C++. Reviewed by John. rdar://20121030 llvm-svn: 234033
* [SystemZ] Fix some ABI corner casesUlrich Weigand2015-03-301-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Running the GCC's inter-compiler ABI compatibility test suite uncovered a couple of errors in clang's SystemZ ABI implementation. These all affect only rare corner cases: - Short vector types GCC synthetic vector types defined with __attribute__ ((vector_size ...)) are always passed and returned by reference. (This is not documented in the official ABI document, but is the de-facto ABI implemented by GCC.) clang would do that only for vector sizes >= 16 bytes, but not for shorter vector types. - Float-like aggregates and empty bitfields clang would consider any aggregate containing an empty bitfield as first element to be a float-like aggregate. That's obviously wrong. According to the ABI doc, the presence of an empty bitfield makes an aggregate to be *not* float-like. However, due to a bug in GCC, empty bitfields are ignored in C++; this patch changes clang to be compatible with this "feature" of GCC. - Float-like aggregates and va_arg The va_arg implementation would mis-detect some aggregates as float-like that aren't actually passed as such. This applies to aggregates that have only a single element of type float or double, but using an aligned attribute that increases the total struct size to more than 8 bytes. This error occurred because the va_arg implement used to have an copy of the float-like aggregate detection logic (i.e. it would call the isFPArgumentType routine, but not perform the size check). To simplify the logic, this patch removes the duplicated logic and instead simply checks the (possibly coerced) LLVM argument type as already determined by classifyArgumentType. llvm-svn: 233543
* Under duress, move check for target support of __builtin_setjmp/Joerg Sonnenberger2015-03-111-30/+0
| | | | | | __builtin_longjmp to Sema as requested by John McCall. llvm-svn: 231986
* [PowerPC] ABI support for the QPX vector instruction setHal Finkel2015-03-111-22/+84
| | | | | | | | | | | | | | Support for the QPX vector instruction set, used on the IBM BG/Q supercomputer, has recently been added to the LLVM PowerPC backend. This vector instruction set requires some ABI modifications because the ABI on the BG/Q expects <4 x double> vectors to be provided with 32-byte stack alignment, and to be handled as native vector types (similar to how Altivec vectors are handled on mainline PPC systems). I've named this ABI variant elfv1-qpx, have made this the default ABI when QPX is supported, and have updated the ABI handling code to provide QPX vectors with the correct stack alignment and associated register-assignment logic. llvm-svn: 231960
* ARM: use ABI-specified alignment for byval parameters.Tim Northover2015-03-091-6/+3
| | | | | | | | | | | | | | | | When passing a type with large alignment byval, we were specifying the type's alignment rather than the alignment that the backend is actually capable of producing (ABIAlign). This would be OK (if odd) assuming the backend dealt with it prooperly, unfortunately it doesn't and trying to pass types with "byval align 16" can cause it to set fp incorrectly and trash the stack during the prologue. I'll be fixing that in a separate patch, but Clang should still be emitting IR that's as close to its intent as possible. rdar://20059039 llvm-svn: 231706
* Fix test/CodeGen/builtins.c for platforms that don't lower sjljReid Kleckner2015-03-041-0/+4
| | | | | | | | Opt in Win64 to supporting sjlj lowering. We have the backend lowering, so I think this was just an oversight because WinX86_64TargetCodeGenInfo doesn't inherit from X86_64TargetCodeGenInfo. llvm-svn: 231280
* CodeGen: Fix passing of classes with only one AVX vector member in AVX registersBenjamin Kramer2015-03-021-15/+4
| | | | | | | | | | | | | | isSingleElementStruct was a bit too tight in its definition of struct so we got a mismatch between classify() and the actual code generation. To make matters worse the code in GetByteVectorType still defaulted to <2 x double> if it encountered a type it didn't know, making this a silent miscompilation (PR22753). Completely remove the "preferred type" stuff from GetByteVectorType and make it fail an assertion if someone tries to use it with a type not suitable for a vector register. llvm-svn: 230971
* Replace loop with equivalent ArrayRef function. NFC.Benjamin Kramer2015-03-021-6/+1
| | | | llvm-svn: 230949
* UBSan: Use the correct function prologue for x32.Peter Collingbourne2015-02-251-4/+15
| | | | llvm-svn: 230571
* ARM: Simplify PCS handling.Tim Northover2015-02-241-179/+9
| | | | | | | | The backend should now be able to handle all AAPCS rules based on argument type, which means Clang no longer has to duplicate the register-counting logic and the CodeGen can be significantly simplified. llvm-svn: 230349
* [WinX86_64 ABI] Treat C99 _Complex as a structMichael Kuperstein2015-02-241-1/+1
| | | | | | | | | MSVC does not support C99 _Complex. ICC, however, does support it on windows x86_64, and treats it, for purposes of parameter passing, as equivalent to a struct containing two fields (for the real and imaginary part). Differential Revision: http://reviews.llvm.org/D7825 llvm-svn: 230315
* Only lower __builtin_setjmp / __builtin_longjmp toJoerg Sonnenberger2015-02-231-0/+25
| | | | | | | | | | llvm.eh.sjlj.setjmp / llvm.eh.sjlj.longjmp, if the backend is known to support them outside the Exception Handling context. The default handling in LLVM codegen doesn't work and will create incorrect code. The ARM backend on the other hand will assert if the intrinsics are used. llvm-svn: 230255
* x86-64 ABI: unwrap single element structs / arrays of 256-bit vectors to ↵Sanjay Patel2015-02-161-11/+7
| | | | | | | | | | | | | | pass and return in registers This is a patch for PR22563 ( http://llvm.org/bugs/show_bug.cgi?id=22563 ). We were not correctly unwrapping a single 256-bit AVX vector that was defined as an array of 1 inside a struct. We would generate a <4 x float> param/return value instead of <8 x float> and lose half of the vector. Differential Revision: http://reviews.llvm.org/D7614 llvm-svn: 229408
* Fix quoting of #pragma comment for MS compat, clang part.Michael Kuperstein2015-02-161-3/+7
| | | | | | | | | For #pragma comment(linker, ...) MSVC expects the comment string to be quoted, but for #pragma comment(lib, ...) the compiler itself quotes the library name. Since this distinction disappears by the time the directive reaches the backend, move quoting for the "lib" version to the frontend. Differential Revision: http://reviews.llvm.org/D7653 llvm-svn: 229376
* CodeGen: create a WindowsARMTargetCodeGenInfoSaleem Abdulrasool2015-01-301-0/+34
| | | | | | | | | Create a new TargetCodeGenInfo for Windows on ARM to permit annotating the functions with stack-probe-size (for /Gs and -mstack-probe-support) for generating the stack probe necessary for Windows targets. This will be used by the backend when lowering the frame to generate the stack probe appropriately. llvm-svn: 227641
* Remove NaClX86_64TargetCodeGenInfo and NaClARMTargetCodeGenInfoDerek Schuff2015-01-291-34/+1
| | | | | | | | | | | | | | | | Summary: They just existed before to use NaCl's custom ABIInfos; now that those are gone, the custom TargetCodeGenInfos are no longer needed either. Test Plan: don't break the existing tests Reviewers: jvoung Subscribers: jfb, cfe-commits Differential Revision: http://reviews.llvm.org/D7234 llvm-svn: 227406
* Remove support for pnaclcall attributeDerek Schuff2015-01-281-57/+2
| | | | | | | | | | | | | | | | | | Summary: It was used for interoperability with PNaCl's calling conventions, but it's no longer needed. Also Remove NaCl*ABIInfo which just existed to delegate to either the portable or native ABIInfo, and remove checkCallingConvention which was now a no-op override. Reviewers: jvoung Subscribers: jfb, llvm-commits Differential Revision: http://reviews.llvm.org/D7206 llvm-svn: 227362
* Begin to teach clang about the PS4.Alex Rosenberg2015-01-271-0/+14
| | | | llvm-svn: 227194
* Implement command line options for stack probe spaceHans Wennborg2015-01-201-0/+33
| | | | | | | | | | | | | This code adds the -mstack-probe-size command line option and implements the /Gs compiler switch for clang-cl. This should fix http://llvm.org/bugs/show_bug.cgi?id=21896 Patch by Andrew H! Differential Revision: http://reviews.llvm.org/D6685 llvm-svn: 226601
* [mips] Handle transparent unions correctly.Daniel Sanders2015-01-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: This fixes MultiSource/Applications/lemon on big-endian N32 by correcting the handling of the argument to wait(). glibc defines it as a transparent union of void* and int*. Such unions are passed according to the rules of the first member so the argument must be passed as if it were a void* (sign extended from i32 to i64) and not as a union (shifted to the upper bits of an i64). wait() already behaves correctly on big-endian O32 and N64 since the union is already the same size as an argument slot. Reviewers: atanasyan Reviewed By: atanasyan Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6963 llvm-svn: 225981
* [cleanup] Re-sort *all* #include lines with llvm/utils/sort_includes.pyChandler Carruth2015-01-141-1/+0
| | | | | | | | | | Sorry for the noise, I managed to miss a bunch of recent regressions of include orderings here. This should actually sort all the includes for Clang. Again, no functionality changed, this is just a mechanical cleanup that I try to run periodically to keep the #include lines as regular as possible across the project. llvm-svn: 225979
* [mips] Fix va_arg() for pointer types on big-endian N32.Daniel Sanders2015-01-131-4/+6
| | | | | | | | | | | | | | | | | | | | | Summary: The Mips ABI's treat pointers in the same way as integers. They are sign-extended to 32-bit for O32, and 64-bit for N32/N64. This doesn't matter for O32 and N64 where pointers are already the correct width but it does matter for big-endian N32, where pointers are 32-bit and need promoting. The caller side is already passing pointers correctly. This patch corrects the callee. Reviewers: vmedic, atanasyan Reviewed By: atanasyan Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6812 llvm-svn: 225782
* R600: Handle amdgcn tripleTom Stellard2015-01-061-0/+2
| | | | | | For now there is no difference between amdgcn and r600. llvm-svn: 225294
* 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
OpenPOWER on IntegriCloud