summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGCall.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Implement the __builtin_call_with_static_chain GNU extension.Peter Collingbourne2014-12-121-35/+62
| | | | | | | | | | | | | | | | 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
* Instead of having -Os/-Oz add OptimizeForSize/MinSize first, and laterPaul Robinson2014-12-111-4/+11
| | | | | | | | | | having OptimizeNone remove them again, just don't add them in the first place if the function already has OptimizeNone. Note that MinSize can still appear due to attributes on different declarations; a future patch will address that. llvm-svn: 224047
* CodeGen: further simplify assertionSaleem Abdulrasool2014-11-251-4/+2
| | | | | | Use more of algorithm to simplify the assertion. Pointed out by David Blakie! llvm-svn: 222721
* CodeGen: use a range-based for loopSaleem Abdulrasool2014-11-241-3/+2
| | | | | | Convert a debug assertion into a range-based loop form. NFC. llvm-svn: 222679
* Update for LLVM API change to make Small(Ptr)Set::insert return ↵David Blaikie2014-11-191-2/+4
| | | | | | pair<iterator, bool> as per the C++ standard's associative container concept. llvm-svn: 222335
* Bundle conditions checked by UBSan with sanitizer kinds they implement.Alexey Samsonov2014-11-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This change makes CodeGenFunction::EmitCheck() take several conditions that needs to be checked (all of them need to be true), together with sanitizer kinds these checks are for. This would allow to split one call into UBSan runtime into several calls in case different sanitizer kinds would have different recoverability settings. Tests should be fixed accordingly, I'm working on it. Test Plan: regression test suite. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D6219 llvm-svn: 221716
* Propagate SanitizerKind into CodeGenFunction::EmitCheck() call.Alexey Samsonov2014-11-101-2/+3
| | | | | | | | | | | | | | | | Make sure CodeGenFunction::EmitCheck() knows which sanitizer it emits check for. Make CheckRecoverableKind enum an implementation detail and move it away from header. Currently CheckRecoverableKind is determined by the type of sanitizer ("unreachable" and "return" are unrecoverable, "vptr" is always-recoverable, all the rest are recoverable). This will change in future if we allow to specify which sanitizers are recoverable, and which are not by -fsanitize-recover= flag. No functionality change. llvm-svn: 221635
* Introduce a SanitizerKind enum to LangOptions.Alexey Samsonov2014-11-071-2/+2
| | | | | | | | | | | | | Use the bitmask to store the set of enabled sanitizers instead of a bitfield. On the negative side, it makes syntax for querying the set of enabled sanitizers a bit more clunky. On the positive side, we will be able to use SanitizerKind to eventually implement the new semantics for -fsanitize-recover= flag, that would allow us to make some sanitizers recoverable, and some non-recoverable. No functionality change. llvm-svn: 221558
* Implement IRGen for the x86 vectorcall conventionReid Kleckner2014-10-311-1/+7
| | | | | | | | | | | | | | | 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
* MS ABI: Properly call global delete when invoking virtual destructorsDavid Majnemer2014-10-311-4/+10
| | | | | | | | | | | | | | | | | | | | Summary: The Itanium ABI approach of using offset-to-top isn't possible with the MS ABI, it doesn't have that kind of information lying around. Instead, we do the following: - Call the virtual deleting destructor with the "don't delete the object flag" set. The virtual deleting destructor will return a pointer to 'this' adjusted to the most derived class. - Call the global delete using the adjusted 'this' pointer. Reviewers: rnk Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5996 llvm-svn: 220993
* Fix ARM HVA classification of classes with non-virtual basesReid Kleckner2014-10-311-6/+45
| | | | | | | | | | | | | | | | 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
* Get rid of SanitizerOptions::Disabled global. NFC.Alexey Samsonov2014-10-301-2/+2
| | | | | | | | | SanitizerOptions is not even a POD now, so having global variable of this type, is not nice. Instead, provide a regular constructor and clear() method, and let each CodeGenFunction has its own copy of SanitizerOptions it uses. llvm-svn: 220920
* Add frontend support for __vectorcallReid Kleckner2014-10-241-1/+7
| | | | | | | | | | | | | Wire it through everywhere we have support for fastcall, essentially. This allows us to parse the MSVC "14" CTP headers, but we will miscompile them because LLVM doesn't support __vectorcall yet. Reviewed By: Aaron Ballman Differential Revision: http://reviews.llvm.org/D5808 llvm-svn: 220573
* Promote null pointer constants used as arguments to variadic functionsReid Kleckner2014-10-101-0/+23
| | | | | | | | | | | | | | | Make it possible to pass NULL through variadic functions on 64-bit Windows targets. The Visual C++ headers define NULL to 0, when they should define it to 0LL on Win64 so that NULL is a pointer-sized integer. Fixes PR20949. Reviewers: thakis, rsmith Differential Revision: http://reviews.llvm.org/D5480 llvm-svn: 219456
* Initial support for the align_value attributeHal Finkel2014-10-021-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for the align_value attribute. This attribute is supported by Intel's compiler (versions 14.0+), and several of my HPC users have requested support in Clang. It specifies an alignment assumption on the values to which a pointer points, and is used by numerical libraries to encourage efficient generation of vector code. Of course, we already have an aligned attribute that can specify enhanced alignment for a type, so why is this additional attribute important? The problem is that if you want to specify that an input array of T is, say, 64-byte aligned, you could try this: typedef double aligned_double attribute((aligned(64))); void foo(aligned_double *P) { double x = P[0]; // This is fine. double y = P[1]; // What alignment did those doubles have again? } the access here to P[1] causes problems. P was specified as a pointer to type aligned_double, and any object of type aligned_double must be 64-byte aligned. But if P[0] is 64-byte aligned, then P[1] cannot be, and this access causes undefined behavior. Getting round this problem requires a lot of awkward casting and hand-unrolling of loops, all of which is bad. With the align_value attribute, we can accomplish what we'd like in a well defined way: typedef double *aligned_double_ptr attribute((align_value(64))); void foo(aligned_double_ptr P) { double x = P[0]; // This is fine. double y = P[1]; // This is fine too. } This attribute does not create a new type (and so it not part of the type system), and so will only "propagate" through templates, auto, etc. by optimizer deduction after inlining. This seems consistent with Intel's implementation (thanks to Alexey for confirming the various Intel-compiler behaviors). As a final note, I would have chosen to call this aligned_value, not align_value, for better naming consistency with the aligned attribute, but I think it would be more useful to users to adopt Intel's name. llvm-svn: 218910
* Use ClangToLLVMArgsMapping in CodeGenTypes::GetFunctionType(). NFC.Alexey Samsonov2014-09-291-178/+196
| | | | | | | | | | | This is the last piece of CGCall code that had implicit assumptions about the order in which Clang arguments are translated to LLVM ones (positions of inalloca argument, sret, this, padding arguments etc.) Now all of this data is encapsulated in ClangToLLVMArgsMapping. If this information would be required somewhere else, this class can be moved to a separate header or pulled into CGFunctionInfo. llvm-svn: 218634
* Introduce CGFunctionInfo::getNumRequiredArgs(). NFC.Alexey Samsonov2014-09-291-6/+2
| | | | | | Save the callers from necessity to special-case on variadic functions. llvm-svn: 218625
* Speedup ClangToLLVMArgMapping construction. NFC.Alexey Samsonov2014-09-291-6/+18
| | | | | | | | Add a method to calculate the number of arguments given QualType expnads to. Use this method in ClangToLLVMArgMapping calculation. This number may be cached in CodeGenTypes for efficiency, if needed. llvm-svn: 218623
* Refactor ABIArgInfo::Expand implementation (NFC).Alexey Samsonov2014-09-291-120/+155
| | | | | | | | Hoist the logic which determines the way QualType is expanded into a separate method. Remove a bunch of copy-paste and simplify getTypesFromArgs() / ExpandTypeFromArgs() / ExpandTypeToArgs() methods. llvm-svn: 218615
* Support the assume_aligned function attributeHal Finkel2014-09-261-54/+71
| | | | | | | | | In addition to __builtin_assume_aligned, GCC also supports an assume_aligned attribute which specifies the alignment (and optional offset) of a function's return value. Here we implement support for the assume_aligned attribute by making use of the @llvm.assume intrinsic. llvm-svn: 218500
* Report source location of returns_nonnull attribute in UBSan reports.Alexey Samsonov2014-09-081-9/+11
| | | | llvm-svn: 217400
* Implement nonnull-attribute sanitizerAlexey Samsonov2014-09-081-11/+46
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements a new UBSan check, which verifies that function arguments declared to be nonnull with __attribute__((nonnull)) are actually nonnull in runtime. To implement this check, we pass FunctionDecl to CodeGenFunction::EmitCallArgs (where applicable) and if function declaration has nonnull attribute specified for a certain formal parameter, we compare the corresponding RValue to null as soon as it's calculated. Test Plan: regression test suite Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits, rnk Differential Revision: http://reviews.llvm.org/D5082 llvm-svn: 217389
* Handle constructors and destructors a bit more uniformly in CodeGen.Rafael Espindola2014-09-081-38/+20
| | | | | | | | | There were code paths that are duplicated for constructors and destructors just because we have both CXXCtorType and CXXDtorsTypes. This patch introduces an unified enum and reduces code deplication a bit. llvm-svn: 217383
* Don't emit prologues or epilogues for naked functions (PR18791, PR20028)Hans Wennborg2014-09-041-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | For naked functions with parameters, Clang would still emit stores in the prologue that would clobber the stack, because LLVM doesn't set up a stack frame. (This shows up in -O0 compiles, because the stores are optimized away otherwise.) For example: __attribute__((naked)) int f(int x) { asm("movl $42, %eax"); asm("retl"); } Would result in: _Z1fi: movl 12(%esp), %eax movl %eax, (%esp) <--- Oops. movl $42, %eax retl Differential Revision: http://reviews.llvm.org/D5183 llvm-svn: 217198
* Make all virtual member pointers use variadic musttail callsReid Kleckner2014-08-291-0/+14
| | | | | | | | | This avoids encoding information about the function prototype into the thunk at the cost of some function prototype bitcast gymnastics. Fixes PR20653. llvm-svn: 216782
* Use store size instead of alloc size when coercing.James Molloy2014-08-291-3/+5
| | | | | | | | | | Previously, EnterStructPointerForCoercedAccess used Alloc size when determining how to convert. This was problematic, because there were situations were the alloc size was larger than the store size. For example, if the first element of a structure were i24 and the destination type were i32, the old code would generate a GEP and a load i24. The code should compare store sizes to ensure the whole object is loaded. I have attached a test case. This patch modifies the output of arm64-be-bitfield.c test case, but the new IR seems to be equivalent, and after -O3, the compiler generates identical ARM assembly. (asr x0, x0, #54) Patch by Thomas Jablin! llvm-svn: 216722
* Properly handle multiple nonnull attributes in CodeGenAlexey Samsonov2014-08-281-15/+25
| | | | llvm-svn: 216638
* Fix regression in r216520: don't apply nonnull to non-pointer functionRichard Smith2014-08-271-2/+11
| | | | | | parameters in the IR. llvm-svn: 216574
* Move some ARM-specific code from CGCall.cpp to TargetInfo.cppOliver Stannard2014-08-271-36/+11
| | | | | | | | | 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
* Simplify creation of a bunch of ArrayRefs by using None, makeArrayRef or ↵Craig Topper2014-08-271-6/+5
| | | | | | just letting them be implicitly created. llvm-svn: 216528
* CGCall: Factor out the logic mapping call arguments to LLVM IR arguments.Alexey Samsonov2014-08-221-223/+314
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This refactoring introduces ClangToLLVMArgMapping class, which encapsulates the information about the order in which function arguments listed in CGFunctionInfo should be passed to actual LLVM IR function, such as: 1) positions of sret, if there is any 2) position of inalloca argument, if there is any 3) position of helper padding argument for each call argument 4) positions of regular argument (there can be many if it's expanded). Simplify several related methods (ConstructAttributeList, EmitFunctionProlog and EmitCall): now they don't have to maintain iterators over the list of LLVM IR function arguments, dealing with all the sret/inalloca/this complexities, and just use expected positions of LLVM IR arguments stored in ClangToLLVMArgMapping. This may increase the running time of EmitFunctionProlog, as we have to traverse expandable arguments twice, but in further refactoring we will be able to speed up EmitCall by passing already calculated CallArgsToIRArgsMapping to ConstructAttributeList, thus avoiding traversing expandable argument there. No functionality change. Test Plan: regression test suite Reviewers: majnemer, rnk Reviewed By: rnk Subscribers: cfe-commits, rjmccall, timurrrr Differential Revision: http://reviews.llvm.org/D4938 llvm-svn: 216251
* Simplify some CodeGenTypes::arrangeXXX functions. No functionality changeAlexey Samsonov2014-08-131-28/+10
| | | | llvm-svn: 215606
* Simplify a few loops over CallArgList/FunctionArgList. NFCAlexey Samsonov2014-08-131-14/+10
| | | | llvm-svn: 215571
* [UBSan] Add returns-nonnull sanitizer.Alexey Samsonov2014-08-131-1/+18
| | | | | | | | | | | | | | | | | | | | Summary: This patch adds a runtime check verifying that functions annotated with "returns_nonnull" attribute do in fact return nonnull pointers. It is based on suggestion by Jakub Jelinek: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140623/223693.html. Test Plan: regression test suite Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D4849 llvm-svn: 215485
* MS ABI: Use musttail for vtable thunks that pass arguments by valueReid Kleckner2014-07-261-13/+2
| | | | | | | | | | | | | This moves some memptr specific code into the generic thunk emission codepath. Fixes PR20053. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D4613 llvm-svn: 214004
* Cleanup comparisons to VariableArrayType::Static for non-VLAsHal Finkel2014-07-191-1/+1
| | | | | | | The enum is part of ArrayType, so there is no functional change, but comparing to ArrayType::Static for non-VLAs makes more sense. llvm-svn: 213446
* Use the dereferenceable attribute on C99 array parameters with staticHal Finkel2014-07-191-1/+37
| | | | | | | | | | | | | | In C99, an array parameter declarator might have the form: direct-declarator '[' 'static' type-qual-list[opt] assign-expr ']' where the static keyword indicates that the caller will always provide a pointer to the beginning of an array with at least the number of elements specified by the assignment expression. For constant sizes, we can use the new dereferenceable attribute to pass this information to the optimizer. For VLAs, we don't know the size, but (for addrspace(0)) do know that the pointer must be nonnull (and so we can use the nonnull attribute). llvm-svn: 213444
* Mark C++ reference parameters as dereferenceableHal Finkel2014-07-181-4/+16
| | | | | | | | | | | | | | Because references must be initialized using some evaluated expression, they must point to something, and a callee can assume the reference parameter is dereferenceable. Taking advantage of a new attribute just added to LLVM, mark them as such. Because dereferenceability in addrspace(0) implies nonnull in the backend, we don't need both attributes. However, we need to know the size of the object to use the dereferenceable attribute, so for incomplete types we still emit only nonnull. llvm-svn: 213386
* Add nonnull in CodeGen for __attribute__((returns_nonnull))Hal Finkel2014-07-121-0/+2
| | | | | | | As a follow-up to r212835, also add the LLVM nonnull function attribute when __attribute__((returns_nonnull)) is provided. llvm-svn: 212874
* Add nonnull in CodeGen for __attribute__((nonnull))Hal Finkel2014-07-111-0/+11
| | | | | | | | We now have an LLVM-level nonnull attribute that can be applied to function parameters, and we emit it for reference types (as of r209723), but did not emit it when an __attribute__((nonnull)) was provided. Now we will. llvm-svn: 212835
* MS ABI: "Fix" passing non-POD structs by value to variadic functionsReid Kleckner2014-07-081-20/+25
| | | | | | | | | | Of course, such code is horribly broken and will explode on impact. That said, ATL does it, and we have to support them, at least a little bit. Fixes PR20191. llvm-svn: 212508
* Add 'nonnull' parameter or return attribute when producing an llvm pointer ↵Nick Lewycky2014-05-281-0/+6
| | | | | | type in a function type where the C++ type is a reference. Update the tests. llvm-svn: 209723
* [C++11] Use 'nullptr'. CodeGen edition.Craig Topper2014-05-211-35/+35
| | | | llvm-svn: 209272
* Implement the flatten attribute.Peter Collingbourne2014-05-201-0/+6
| | | | | | | | | | This is a GNU attribute that causes calls within the attributed function to be inlined where possible. It is implemented by giving such calls the alwaysinline attribute. Differential Revision: http://reviews.llvm.org/D3816 llvm-svn: 209217
* Implement the no_split_stack attribute.Peter Collingbourne2014-05-191-1/+2
| | | | | | | | | This is a GNU attribute that allows split stacks to be turned off on a per-function basis. Differential Revision: http://reviews.llvm.org/D3817 llvm-svn: 209167
* MS ABI: Use musttail for thunk IR generationReid Kleckner2014-05-151-1/+1
| | | | | | | | | | | This allows us to perfectly forward non-trivial arguments that use inalloca. We still can't forward non-trivial arguments through thunks when we have a covariant return type with a non-trivial adjustment. This would require emitting an extra copy, which is non-conforming anyway. llvm-svn: 208927
* MS ABI: Pass 'sret' as the second parameter of instance methodsReid Kleckner2014-05-091-13/+52
| | | | | | | | | | | | | | | | | Summary: MSVC always passes 'sret' after 'this', unlike GCC. This required changing a number of places in Clang that assumed the sret parameter was always first in LLVM IR. This fixes win64 MSVC ABI compatibility for methods returning structs. Reviewers: rsmith, majnemer Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D3618 llvm-svn: 208458
* Reapply r208417 (olista01 'ARM: HFAs must be passed in consecutive ↵James Molloy2014-05-091-8/+34
| | | | | | registers'). Bots are now pacified. llvm-svn: 208425
* Revert r208417 (olista01 'ARM: HFAs must be passed in consecutive ↵James Molloy2014-05-091-34/+8
| | | | | | registers'). This is a followon commit from r208413 which broke the LLVM bots. llvm-svn: 208422
* ARM: HFAs must be passed in consecutive registersOliver Stannard2014-05-091-8/+34
| | | | | | | This is the clang counterpart to 208413, which ensures that Homogeneous Floating-point Aggregates are passed in consecutive registers on ARM. llvm-svn: 208417
OpenPOWER on IntegriCloud