summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGCall.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Always add the target-cpu and target-features sets if they're non-null.Eric Christopher2015-04-271-9/+9
| | | | | | | | This makes sure that the front end is specific about what they're expecting the backend to produce. Update a FIXME with the idea that the target-features could be more precise using backend knowledge. llvm-svn: 235936
* [MS ABI] Fix the preferred alignment of member pointersDavid Majnemer2015-04-241-2/+1
| | | | | | | Member pointers in the MS ABI have different alignment depending on whether they were created on the stack or live in a record. llvm-svn: 235681
* Revert "Revert r234581, it might have caused a few miscompiles in Chromium."David Majnemer2015-04-221-2/+26
| | | | | | | | This reverts commit r234700. It turns out that the lifetime markers were not the cause of Chromium failing but a bug which was uncovered by optimizations exposed by the markers. llvm-svn: 235553
* Revert r234581, it might have caused a few miscompiles in Chromium.Nico Weber2015-04-111-26/+2
| | | | | | | If the revert helps, I'll get a repro this Monday. Else I'll put the change back in. llvm-svn: 234700
* Don't rely on implicit CallSite construction.Benjamin Kramer2015-04-101-1/+1
| | | | llvm-svn: 234600
* Remove threshold for inserting lifetime markers for named temporariesArnaud A. de Grandmaison2015-04-101-2/+26
| | | | | | | | | | | | | | | | | | | Now that TailRecursionElimination has been fixed with r222354, the threshold on size for lifetime marker insertion can be removed. This only affects named temporary though, as the patch for unnamed temporaries is still in progress. My previous commit (r222993) was not handling debuginfo correctly, but this could only be seen with some asan tests. Basically, lifetime markers are just instrumentation for the compiler's usage and should not affect debug information; however, the cleanup infrastructure was assuming it contained only destructors, i.e. actual code to be executed, and was setting the breakpoint for the end of the function to the closing '}', and not the return statement, in order to show some destructors have been called when leaving the function. This is wrong when the cleanups are only lifetime markers, and this is now fixed. llvm-svn: 234581
* clang-format my last commitDavid Blaikie2015-04-051-8/+13
| | | | | | (sorry, keep forgetting that) llvm-svn: 234129
* [opaque pointer type] More GEP API migrationsDavid Blaikie2015-04-051-9/+10
| | | | | | | 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-7/+9
| | | | llvm-svn: 234109
* [opaque pointer type] Explicitly specify some types for GEPDavid Blaikie2015-04-031-4/+5
| | | | | | | Not all of them (there's still a fallback for this specific function that omits the type parameter) but it's some I bothered to do now. llvm-svn: 234063
* DebugInfo: Use new LLVM API for DebugLocDuncan P. N. Exon Smith2015-03-301-1/+1
| | | | | | | Use the new API for `DebugLoc` added in r233573 before the old one disappears. llvm-svn: 233589
* Reapply r232888 after applying a fix for -msse4 code generation.Eric Christopher2015-03-251-0/+21
| | | | | | | As a note, any target that uses fake target features via command line options will have similar problems. llvm-svn: 233227
* Revert "Add CodeGen support for adding cpu attributes on functions based on"Daniel Jasper2015-03-231-21/+0
| | | | | | | This breaks CodeGen for an internal target. I'll get repro instructions to you. llvm-svn: 232930
* Add CodeGen support for adding cpu attributes on functions based onEric Christopher2015-03-211-0/+21
| | | | | | | | | | | | | the target-cpu, if different from the triple's cpu, and target-features as they're written that are passed down from the driver. Together with LLVM r232885 this should allow the LTO'ing of binaries that contain modules compiled with different code generation options on a subset of architectures with full backend support (x86, powerpc, aarch64). llvm-svn: 232888
* MS ABI: Generate default constructor closuresDavid Majnemer2015-03-131-2/+6
| | | | | | | | | | | | | | | | | | | | The MS ABI utilizes a compiler generated function called the "vector constructor iterator" to construct arrays of objects with non-trivial constructors/destructors. For this to work, the constructor must follow a specific calling convention. A thunk must be created if the default constructor has default arguments, is variadic or is otherwise incompatible. This thunk is called the default constructor closure. N.B. Default constructor closures are only generated if the default constructor is exported because clang itself does not utilize vector constructor iterators. Failing to export the default constructor closure will result in link/load failure if a translation unit compiled with MSVC is on the import side. Differential Revision: http://reviews.llvm.org/D8331 llvm-svn: 232229
* MS ABI: Implement copy-ctor closures, finish implementing throwDavid Majnemer2015-03-111-0/+16
| | | | | | | | | | | | | | | This adds support for copy-constructor closures. These are generated when the C++ runtime has to call a copy-constructor with a particular calling convention or with default arguments substituted in to the call. Because the runtime has no mechanism to call the function with a different calling convention or know-how to evaluate the default arguments at run-time, we create a thunk which will do all the appropriate work and package it in a way the runtime can use. Differential Revision: http://reviews.llvm.org/D8225 llvm-svn: 231952
* Update for LLVM API change: getOrEnforceKnownAlignment() requires a DataLayoutMehdi Amini2015-03-101-2/+2
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231739
* Prefer SmallVector::append/insert over push_back loops. Clang edition.Benjamin Kramer2015-02-171-4/+2
| | | | | | Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229508
* SEH: Use the SEHTryEpilogueStack instead of a separate boolReid Kleckner2015-02-121-1/+1
| | | | | | We don't need a bool to track this now that we have a stack for it. llvm-svn: 228982
* Add the 'noinline' attribute to call sites within __try bodiesReid Kleckner2015-02-111-0/+6
| | | | | | | LLVM doesn't support non-call exceptions, so inlining makes it harder to catch such asynchronous exceptions. llvm-svn: 228876
* Emit landing pads for SEH even if nounwind is presentReid Kleckner2015-02-111-1/+2
| | | | | | | Disabling exceptions applies nounwind to lots of functions. SEH catches asynch exceptions, so emit the landing pad anyway. llvm-svn: 228769
* DebugInfo: Refactor default arg handling into a common place (instead of ↵David Blaikie2015-02-091-0/+14
| | | | | | handling in repeatedly for aggregate, complex, and scalar types) llvm-svn: 228591
* CodeGen: Move DebugLocs.Benjamin Kramer2015-02-071-1/+1
| | | | | | | | It's slightly cheaper than copying it, if the DebugLoc points to replaceable metadata every copy is recorded in a DenseMap, moving reduces the peak size of that map. llvm-svn: 228492
* Sema: Add support for __declspec(restrict)David Majnemer2015-02-041-1/+1
| | | | | | | | | | __declspec(restrict) and __attribute(malloc) are both handled identically by clang: they are allowed to the noalias LLVM attribute. Seeing as how noalias models the C99 notion of 'restrict', rename the internal clang attribute to Restrict from Malloc. llvm-svn: 228120
* Remove support for pnaclcall attributeDerek Schuff2015-01-281-3/+0
| | | | | | | | | | | | | | | | | | 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
* DebugInfo: Remove forced column-info workaround for inlined callsDavid Blaikie2015-01-211-2/+1
| | | | | | | | | | | | | | | | | This workaround was to provide unique call sites to ensure LLVM's inline debug info handling would properly unique two calls to the same function on the same line. Instead, this has now been fixed in LLVM (r226736) and the workaround here can be removed. Originally committed in r176895, but this isn't a straight revert due to all the changes since then. I just searched for anything ForcedColumn* related and removed them. We could test this - but it didn't strike me as terribly valuable once we're no longer adding this workaround everything just works as expected & it's no longer a special case to test for. llvm-svn: 226738
* Re-apply "r226548 - Introduce SPIR calling conventions" reverted in r226558.Alexander Kornienko2015-01-201-0/+2
| | | | | | | | | | | | | | | | | | | | | | | The test was fixed after a discussion with the revision author: the check pattern was made more flexible as the "%call" part is not what we actually want to check strictly there. The original patch description: === Introduce SPIR calling conventions. This implements Section 3.7 from the SPIR 1.2 spec: SPIR kernels should use "spir_kernel" calling convention. Non-kernel functions use "spir_func" calling convention. All other calling conventions are disallowed. The patch works only for OpenCL source. Any other uses will need to ensure that kernels are assigned the spir_kernel calling convention correctly. === llvm-svn: 226561
* Reverting r226548 as one of the tests fails in some configurations.Alexander Kornienko2015-01-201-2/+0
| | | | | | | | | | | | | | | | | | | | | | Here's the fail log from our internal setup: === .../tools/clang/clang -cc1 -internal-isystem .../tools/clang/staging/include -nostdsysteminc .../tools/clang/test/CodeGenOpenCL/spir-calling-conv.cl -triple spir-unknown-unknown -emit-llvm -o - FileCheck .../tools/clang/test/CodeGenOpenCL/spir-calling-conv.cl .../tools/clang/test/CodeGenOpenCL/spir-calling-conv.cl:11:12: error: expected string not found in input // CHECK: %call = tail call spir_func i32 @get_dummy_id(i32 0) ^ <stdin>:6:52: note: scanning from here define spir_kernel void @foo(i32 addrspace(1)* %A) #0 { ^ <stdin>:7:2: note: possible intended match here %1 = tail call spir_func i32 @get_dummy_id(i32 0) #2 ^ === Here's a failure on a public CI server: http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check/1183/ llvm-svn: 226558
* Introduce SPIR calling conventions.Sameer Sahasrabuddhe2015-01-201-0/+2
| | | | | | | | | | | | | | This implements Section 3.7 from the SPIR 1.2 spec: SPIR kernels should use "spir_kernel" calling convention. Non-kernel functions use "spir_func" calling convention. All other calling conventions are disallowed. The patch works only for OpenCL source. Any other uses will need to ensure that kernels are assigned the spir_kernel calling convention correctly. llvm-svn: 226548
* Recommit r225083 (reverted in r225361) now that calls to aggregate ↵David Blaikie2015-01-181-8/+0
| | | | | | | | | | | | | | | | | | | initializers from in class non-static data members are explicitly attributed to the desired line. The code setting the debug location being removed here was accidentally leaking a location into the call to the non-static data member's ctor call. Without it the call had no location and could cause assertion failures if it was inlined. Now that it has a location (and a correct one at that) this code should hopefully be no longer needed. It's possible of course that other parts of the debug info are also relying on the debug locations being set here to leak to where they're needed - so we might see the same assertions again & will have to investigate what the dependence was/is. But the chances are good that any of those are debug info line table quality bugs we've just not found yet anyway - so it'll be good to flush them out. llvm-svn: 226383
* Revert r225085, it caused PR22096.Nico Weber2015-01-071-0/+8
| | | | | | | | PR22096 has several test cases that assert that look fairly different. I'm adding one of those as an automated test, but when relanding the other cases should probably be checked as well. llvm-svn: 225361
* DebugInfo: Remove some now-unnecessary location handling around function ↵David Blaikie2015-01-021-8/+0
| | | | | | | | | | | | | | arguments. r225000 generalized debug info line info handling for expressions such that this code is no longer necessary. This removes the last use of CGDebugInfo::getLocation, but not all the uses of CGDebugInfo::CurLoc, which is still used internally in CGDebugInfo. I'd like to do away with all of that & might succeed after a few more patches. llvm-svn: 225085
* 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
OpenPOWER on IntegriCloud