summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/TargetInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [WebAssembly] Initial WebAssembly support in clangDan Gohman2015-09-031-0/+81
| | | | | | | | | | This implements basic support for compiling (though not yet assembling or linking) for a WebAssembly target. Note that ABI details are not yet finalized, and may change. Differential Revision: http://reviews.llvm.org/D12002 llvm-svn: 246814
* [ARM] Allow passing/returning of __fp16 argumentsOliver Stannard2015-09-031-0/+20
| | | | | | | | | | | | | | | | | | | | | The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be used as a functon argument or return type (ACLE 1.1 did not). The current public release of the AAPCS (2.09) states that __fp16 values should be converted to single-precision before being passed or returned, but AAPCS 2.10 (to be released shortly) changes this, so that they are passed in the least-significant 16 bits of either a GPR (for base AAPCS) or a single-precision register (for AAPCS-VFP). This does not change how arguments are passed if they get passed on the stack. This patch brings clang up to compliance with the latest versions of both of these specs. We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support the alternative format). llvm-svn: 246764
* Revert 246755 as it breaks buildbotsOliver Stannard2015-09-031-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | Original commit message: [ARM] Allow passing/returning of __fp16 arguments The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be used as a functon argument or return type (ACLE 1.1 did not). The current public release of the AAPCS (2.09) states that __fp16 values should be converted to single-precision before being passed or returned, but AAPCS 2.10 (to be released shortly) changes this, so that they are passed in the least-significant 16 bits of either a GPR (for base AAPCS) or a single-precision register (for AAPCS-VFP). This does not change how arguments are passed if they get passed on the stack. This patch brings clang up to compliance with the latest versions of both of these specs. We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support the alternative format). llvm-svn: 246760
* [ARM] Allow passing/returning of __fp16 argumentsOliver Stannard2015-09-031-0/+18
| | | | | | | | | | | | | | | | | | | | | The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be used as a functon argument or return type (ACLE 1.1 did not). The current public release of the AAPCS (2.09) states that __fp16 values should be converted to single-precision before being passed or returned, but AAPCS 2.10 (to be released shortly) changes this, so that they are passed in the least-significant 16 bits of either a GPR (for base AAPCS) or a single-precision register (for AAPCS-VFP). This does not change how arguments are passed if they get passed on the stack. This patch brings clang up to compliance with the latest versions of both of these specs. We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support the alternative format). llvm-svn: 246755
* Remove raw_svector_ostream::resync and users. It's no-op after r244870.Yaron Keren2015-08-131-2/+0
| | | | llvm-svn: 244888
* Correct x86_64 fp128 calling conventionChih-Hung Hsieh2015-08-101-12/+27
| | | | | | | | | | | | | | | | These changes are for Android x86_64 targets to be compatible with current Android g++ and conform to AMD64 ABI. https://llvm.org/bugs/show_bug.cgi?id=23897 * Return type of long double (fp128) should be fp128, not x86_fp80. * Vararg of long double (fp128) could be in register and overflowed to memory. https://llvm.org/bugs/show_bug.cgi?id=24111 * Return value of long double (fp128) _Complex should be in memory like a structure of {fp128,fp128}. Differential Revision: http://reviews.llvm.org/D11437 llvm-svn: 244468
* Fix -Wextra-semi warnings.Hans Wennborg2015-07-221-3/+3
| | | | | | | | Patch by Eugene Zelenko! Differential Revision: http://reviews.llvm.org/D11401 llvm-svn: 242931
* Fix quoting of #pragma comment for PS4.Yunzhong Gao2015-07-201-1/+5
| | | | | | | | | | | | This is the PS4 counterpart to r229376, which quotes the library name if the name contains space. It was discovered that if a library name contains both double-quote and space characters, quoting the name might produce unexpected results, but we are mostly concerned with a Windows host environment, which does not allow double-quote or slashes in file/folder names. Differential Revision: http://reviews.llvm.org/D11275 llvm-svn: 242689
* [CodeGen, X86] Classify vectors <= 32 bits as INTEGERDavid Majnemer2015-07-171-6/+8
| | | | | | | | | | We shouldn't crash despite the AMD64 ABI not giving clear guidance as to how to pass around vector types <= 32 bits. Instead, classify such vectors as INTEGER to be compatible with GCC. This fixes PR24162. llvm-svn: 242508
* [MIPS] Add support for direct-to-nacl in ClangPetar Jovanovic2015-07-081-0/+2
| | | | | | | | | | | For Mips direct-to-nacl, the goal is to be close to le32 front-end and use Mips32EL backend. This patch defines new NaClMips32ELTargetInfo and modifies it slightly to be close to le32. It also adds necessary parts, inline with ARM and X86. Differential Revision: http://reviews.llvm.org/D10739 llvm-svn: 241678
* [CodeGen] Correctly handle base classes which are passed in memoryDavid Majnemer2015-07-081-2/+4
| | | | | | | | | | | We didn't correctly process the case where a base class is classified as MEMORY. This would cause us to trip over an assertion. This fixes PR24020. Differential Revision: http://reviews.llvm.org/D10907 llvm-svn: 241667
* [CodeGen] Don't crash classifying a union of an AVX vector and an intDavid Majnemer2015-07-081-0/+2
| | | | | | | | | | | | We forgot to run postMerge after decided that the union had to be classified as MEMORY. This left us with Lo == MEMORY and Hi == SSEUp which is an invalid combination. This fixes PR24021. Differential Revision: http://reviews.llvm.org/D10908 llvm-svn: 241666
* [OPENMP] Introduced type trait "__builtin_omp_required_simd_align" for ↵Alexey Bataev2015-07-021-33/+3
| | | | | | | | | default simd alignment. Adds type trait "__builtin_omp_required_simd_align" after discussions here http://reviews.llvm.org/D9894 Differential Revision: http://reviews.llvm.org/D10597 llvm-svn: 241237
* update commentDerek Schuff2015-06-241-2/+4
| | | | llvm-svn: 240601
* Relax assertion in x86_64 byval argument handling for 32-bit pointersDerek Schuff2015-06-241-1/+2
| | | | | | | | | | | | | | | | Summary: Byval argument pair formation assumes that if a type is less than 8 bytes it must be an integer and not a pointer, which is not true for x32 and NaCl. Relax the assertion and add a test for a codegen case that triggered it. Reviewers: jvoung Subscribers: jfb, cfe-commits Differential Revision: http://reviews.llvm.org/D10701 llvm-svn: 240600
* Silence VC warning C4715: '`anonymous namespace'::getNativeVectorSizeForA ↵Yaron Keren2015-06-231-0/+1
| | | | | | | | VXABI' : not all control paths return a value. llvm-svn: 240389
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-13/+13
| | | | llvm-svn: 240353
* [CodeGen] Teach X86_64ABIInfo about AVX512.Ahmed Bougacha2015-06-221-2/+9
| | | | | | | | | | | | | | | | As specified in the SysV AVX512 ABI drafts. It follows the same scheme as AVX2: Arguments of type __m512 are split into eight eightbyte chunks. The least significant one belongs to class SSE and all the others to class SSEUP. This also means we change the OpenMP SIMD default alignment on AVX512. Based on r240337. Differential Revision: http://reviews.llvm.org/D9894 llvm-svn: 240338
* [CodeGen] Use enum for AVX level in X86*TargetCodeGenInfo. NFCI.Ahmed Bougacha2015-06-221-21/+44
| | | | | | | Follow-up to r237989: expressing the AVX level as an enum makes it simple to extend it with AVX512. llvm-svn: 240337
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-13/+13
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* Rename the single non-style conformant function in TargetCodeGenInfoEric Christopher2015-06-051-21/+21
| | | | | | and update all callers. llvm-svn: 239193
* [x86-64 ABI] Fix for PR23082: an assertion failure when passing/returning a ↵Andrea Di Biagio2015-06-021-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | wrapper union in a full YMM register. This patch fixes an assertion failure in method 'X86_64ABIInfo::GetByteVectorType'. Method 'GetByteVectorType' (in TargetInfo.cpp) is responsible for mapping a QualType 'Ty' (for an argument or return value) to an LLVM IR type that, according to the ABI, must be passed in a XMM/YMM vector register. When selecting the IR vector type, method 'GetByteVectorType' always tries to choose the "best" IR vector type for the 'Ty' in input. In particular, if Ty is a wrapper structure, it keeps unwrapping it until it finds a vector type VTy. That VTy is the "preferred IR type". However, function 'isSingleElementStructure' (used to unwrap structures) does not know how to look through union types. So, before this patch, if Ty was in a nest of wrapper structures with at least two union types, we would have triggered an assertion failure (added at revision 230971). With this patch, if method 'GetByteVectorType' fails to find the preferred vector type, we just return a valid (although potentially 'less friendly') vector type based on the type size. So, rather than asserting on an 'unexpected' 'Ty' in input, we conservatively return vector type <2 x double> if Ty is 16 bytes, or <4 x double> if Ty is 32 bytes. Differential Revision: http://reviews.llvm.org/D10190 llvm-svn: 238861
* Fix 80-column violations.Eric Christopher2015-05-291-60/+77
| | | | llvm-svn: 238630
* Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial typesBenjamin Kramer2015-05-291-1/+1
| | | | | | | | | | | | | | | | | | | | If the type isn't trivially moveable emplace can skip a potentially expensive move. It also saves a couple of characters. Call sites were found with the ASTMatcher + some semi-automated cleanup. memberCallExpr( argumentCountIs(1), callee(methodDecl(hasName("push_back"))), on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))), hasArgument(0, bindTemporaryExpr( hasType(recordDecl(hasNonTrivialDestructor())), has(constructExpr()))), unless(isInTemplateInstantiation())) No functional change intended. llvm-svn: 238601
* [MIPS] Re-land the change r238200 to fix extension of integer typesPetar Jovanovic2015-05-261-0/+15
| | | | | | | | Re-land the change r238200, but with modifications in the tests that should prevent new failures in some environments as reported with the original change on the mailing list. llvm-svn: 238253
* Revert r238200: "[MIPS] fix extension of integer types (function calls)"Hans Wennborg2015-05-261-15/+0
| | | | | | mips-unsigned-ext-var.c and mips-unsigned-extend.c fail in some builds. llvm-svn: 238237
* [MIPS] fix extension of integer types (function calls)Petar Jovanovic2015-05-261-0/+15
| | | | | | | | | | On MIPS unsigned int type should not be zero extended but sign-extended. Patch by Strahinja Petrovic. Differential Revision: http://reviews.llvm.org/D9198 llvm-svn: 238200
* [CodeGen] Use TargetInfo::getABI() throughout X86*TargetCodeGenInfo.Ahmed Bougacha2015-05-221-22/+21
| | | | | | | | | We already have the ABI, we don't need a "HasAVX" flag. This will also makes it easier to add an AVX512 ABI. No functional change intended. llvm-svn: 237989
* Revert changes to DefaultABIInfo accidentally introduced in r208733Reid Kleckner2015-05-181-1/+9
| | | | | | | | | | | | Also add trivial handling of transparent unions. PPC32, MSP430, and XCore apparently all rely on DefaultABIInfo. This should worry you, because DefaultABIInfo is not implementing the rules of any particular ABI. Fixes PR23097, patch by Andy Gibbs. llvm-svn: 237630
* [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
OpenPOWER on IntegriCloud