summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* MS ABI: Emit more canonical vbptr stores and loadsReid Kleckner2014-10-221-4/+12
| | | | | | | | This eliminates some i8* GEPs and makes the IR that clang emits a bit more canonical. More work is needed for vftables, but that isn't a clear win so I plan to send it for review. llvm-svn: 220398
* R600: Update for div_fmas intrinsic changeMatt Arsenault2014-10-211-2/+11
| | | | llvm-svn: 220339
* Fixing the MSVC build by removing friendship with CodeGenFunction; NFC.Aaron Ballman2014-10-211-1/+0
| | | | llvm-svn: 220293
* [OPENMP] Codegen for 'private' clause in 'parallel' directive.Alexey Bataev2014-10-213-2/+37
| | | | | | | This patch generates some helper variables which used as a private copies of the corresponding original variables inside an OpenMP 'parallel' directive. These generated variables are initialized by default (with the default constructor, if any). In outlined function references to original variables are replaced by the references to these private helper variables. At the end of the initialization of the private variables and implicit barier is set by calling __kmpc_barrier(...) runtime function to be sure that all threads were initialized using original values of the variables. Differential Revision: http://reviews.llvm.org/D4752 llvm-svn: 220262
* Lower compound assignment for the missing type llvm::Type::FP128TyID.Jiangning Liu2014-10-211-0/+4
| | | | llvm-svn: 220257
* Fix whitespace introduced in r220221David Blaikie2014-10-201-1/+1
| | | | | | Post commit review feedback from Yaron Keren. llvm-svn: 220229
* PR21312: Fix a regression in non-type template parameters of function type ↵David Blaikie2014-10-201-2/+3
| | | | | | that are static member functions. llvm-svn: 220221
* Fix indentation.David Blaikie2014-10-201-1/+1
| | | | llvm-svn: 220216
* CodeGen: Update for LLVM API changeDavid Majnemer2014-10-201-1/+1
| | | | | | | Callers of DataLayout::RoundUpAlignment should switch to RoundUpToAlignment. llvm-svn: 220188
* CodeGen: ConstStructBuilder must verify packed constraints after paddingDavid Majnemer2014-10-191-14/+30
| | | | | | | | | | | | | | | | | | This reverts commit r220169 which reverted r220153. However, it also contains additional changes: - We may need to add padding *after* we've packed the struct. This occurs when the aligned next field offset is greater than the new field's offset. When this occurs, we make the struct packed. *However*, once packed the next field offset might be less than the new feild's offset. It is in this case that we might further pad the struct. - We would pad structs which were perfectly sized! This behavior is immensely old. This behavior came from blindly subtracting NextFieldOffsetInChars from RecordSize. This doesn't take into account the fact that the struct might have a greater overall alignment than the last field. llvm-svn: 220175
* Revert r220153: "CodeGen: ConstStructBuilder must verify packed constraints ↵Chandler Carruth2014-10-191-10/+9
| | | | | | | | | | after padding" This commit caused two tests in LNT to regress. I'm able to reproduce on any platform and will send reproduction steps to the original commit log. This should restore the LNT bots that have been failing. llvm-svn: 220169
* [complex] Teach the complex math IR gen to emit direct math andChandler Carruth2014-10-191-17/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | a NaN-test prior to the call to the library function. This should automatically make fastmath (including just non-NaNs) able to avoid the expensive libcalls and also open the door to more advanced folding in LLVM based on the rules for complex math. Two important notes to remember: first is that this isn't yet a proper limited range mode, it's still just improving the unlimited range mode. Also, it isn't really perfecet w.r.t. what an unlimited range mode should be doing because it isn't quite handling the flags produced by all the operations in the way desirable for that mode, but then neither is compiler-rt's libcall. When the compiler-rt libcall is improved to carefully manage flags, the code emitted here should be improved correspondingly. And it is still a long-term desirable thing to add a limited range mode to Clang that would be able to use direct math without library calls here. Special thanks to Steve Canon for the careful review on this patch and teaching me about these issues. =D Differential Revision: http://reviews.llvm.org/D5756 llvm-svn: 220167
* CodeGen: ConstStructBuilder must verify packed constraints after paddingDavid Majnemer2014-10-191-9/+10
| | | | | | | | | | | | Before, ConstStructBuilder::AppendBytes would check packed constraints prior to padding being added before the field's offset. However, adding this padding might force our struct to be packed. Because we wouldn't check *after* adding padding, ConstStructBuilder would be in an inconsistent state leading to a crash. This fixes PR21300. llvm-svn: 220153
* PR21305: Typedefs in non-type template parameters in member data pointers.David Blaikie2014-10-181-1/+1
| | | | | | Patch by Stephen Crane! llvm-svn: 220122
* [ASan] Improve blacklisting of global variables.Alexey Samsonov2014-10-174-7/+43
| | | | | | | | | | | | | | | | | | | | | | | | | This commit changes the way we blacklist global variables in ASan. Now the global is excluded from instrumentation (either regular bounds checking, or initialization-order checking) if: 1) Global is explicitly blacklisted by its mangled name. This part is left unchanged. 2) SourceLocation of a global is in blacklisted source file. This changes the old behavior, where instead of looking at the SourceLocation of a variable we simply considered llvm::Module identifier. This was wrong, as identifier may not correspond to the file name, and we incorrectly disabled instrumentation for globals coming from #include'd files. 3) Global is blacklisted by type. Now we build the type of a global variable using Clang machinery (QualType::getAsString()), instead of llvm::StructType::getName(). After this commit, the active users of ASan blacklist files may have to revisit them (this is a backwards-incompatible change). llvm-svn: 220097
* fix -fsanitize-address-field-padding for the cases with virtual base classesKostya Serebryany2014-10-171-3/+1
| | | | | | | | | | | | | | | | Summary: Correctly compute the non-virtual size of a class. Test Plan: Build SPEC 2016 with -fsanitize-address-field-padding Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5848 llvm-svn: 220089
* Rename TemplateArgument::getTypeForDecl to getParamTypeForDecl for clarityDavid Blaikie2014-10-171-9/+6
| | | | | | Code review feedback from Richard Smith on r219900. llvm-svn: 220060
* complex long double support for PowerPCJoerg Sonnenberger2014-10-171-0/+4
| | | | llvm-svn: 220034
* CodeGen: Kill FillInNullDataMemberPointersDavid Majnemer2014-10-171-106/+3
| | | | | | | It exists to handle the case where base subobjects are character arrays. This never happens. llvm-svn: 220006
* SanitizerBlacklist: blacklist functions by their source location.Alexey Samsonov2014-10-178-22/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit changes the way we blacklist functions in ASan, TSan, MSan and UBSan. We used to treat function as "blacklisted" and turned off instrumentation in it in two cases: 1) Function is explicitly blacklisted by its mangled name. This part is not changed. 2) Function is located in llvm::Module, whose identifier is contained in the list of blacklisted sources. This is completely wrong, as llvm::Module may not correspond to the actual source file function is defined in. Also, function can be defined in a header, in which case user had to blacklist the .cpp file this header was #include'd into, not the header itself. Such functions could cause other problems - for instance, if the header was included in multiple source files, compiled separately and linked into a single executable, we could end up with both instrumented and non-instrumented version of the same function participating in the same link. After this change we will make blacklisting decision based on the SourceLocation of a function definition. If a function is not explicitly defined in the source file, (for example, the function is compiler-generated and responsible for initialization/destruction of a global variable), then it will be blacklisted if the corresponding global variable is defined in blacklisted source file, and will be instrumented otherwise. After this commit, the active users of blacklist files may have to revisit them. This is a backwards-incompatible change, but I don't think it's possible or makes sense to support the old incorrect behavior. I plan to make similar change for blacklisting GlobalVariables (which is ASan-specific). llvm-svn: 219997
* Insert poisoned paddings between fields in C++ classes so that ↵Kostya Serebryany2014-10-162-1/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | AddressSanitizer can find intra-object-overflow bugs Summary: The general approach is to add extra paddings after every field in AST/RecordLayoutBuilder.cpp, then add code to CTORs/DTORs that poisons the paddings (CodeGen/CGClass.cpp). Everything is done under the flag -fsanitize-address-field-padding. The blacklist file (-fsanitize-blacklist) allows to avoid the transformation for given classes or source files. See also https://code.google.com/p/address-sanitizer/wiki/IntraObjectOverflow Test Plan: run SPEC2006 and some of the Chromium tests with -fsanitize-address-field-padding Reviewers: samsonov, rnk, rsmith Reviewed By: rsmith Subscribers: majnemer, cfe-commits Differential Revision: http://reviews.llvm.org/D5687 llvm-svn: 219961
* MS Compat: mark globals emitted in read-only sections constHans Wennborg2014-10-161-0/+7
| | | | | | | | | | | | | | | | | | | | They cannot be written to, so marking them const makes sense and may improve optimisation. As a side-effect, SectionInfos has to be moved from Sema to ASTContext. It also fixes this problem, that occurs when compiling ATL: warning LNK4254: section 'ATL' (C0000040) merged into '.rdata' (40000040) with different attributes The ATL headers are putting variables in a special section that's marked read-only. However, Clang currently can't model that read-onlyness in the IR. But, by making the variables const, the section does become read-only, and the linker warning is avoided. Differential Revision: http://reviews.llvm.org/D5812 llvm-svn: 219960
* PR21246: DebugInfo: Emit the appropriate type (cv qualifiers, ↵David Blaikie2014-10-161-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | reference-ness, etc) for non-type template parameters Plumb through the full QualType of the TemplateArgument::Declaration, as it's insufficient to only know whether the type is a reference or pointer (that was necessary for mangling, but insufficient for debug info). This shouldn't increase the size of TemplateArgument as TemplateArgument::Integer is still longer by another 32 bits. Several bits of code were testing that the reference-ness of the parameters matched, but this seemed to be insufficient (various other features of the type could've mismatched and wouldn't've been caught) and unnecessary, at least insofar as removing those tests didn't cause anything to fail. (Richard - perchaps you can hypothesize why any of these checks might need to test reference-ness of the parameters (& explain why reference-ness is part of the mangling - I would've figured that for the reference-ness to be different, a prior template argument would have to be different). I'd be happy to add them in/beef them up and add test cases if there's a reason for them) llvm-svn: 219900
* Moving CGF::EmitAlignmentAssumption to IRBuilderHal Finkel2014-10-152-30/+4
| | | | | | | | The functionality contained in CodeGenFunction::EmitAlignmentAssumption has been moved to IRBuilder (so that it can also be used by LLVM-level code). Remove this now-duplicate implementation in favor of the IRBuilder code. llvm-svn: 219877
* CodeGen: Don't drop thread_local when emitting __thread aliasesDavid Majnemer2014-10-152-10/+18
| | | | | | | | | | | | CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a tentative definition. Even if the definition was already emitted, it would never mark the alias as thread_local. This fixes PR21288. llvm-svn: 219859
* Move SanitizerBlacklist object from CodeGenModule to ASTContext.Alexey Samsonov2014-10-152-7/+3
| | | | | | | | Soon we'll need to have access to blacklist before the CodeGen phase (see http://reviews.llvm.org/D5687), so parse and construct the blacklist earlier. llvm-svn: 219857
* Move -fsanitize-blacklist to LangOpts from CodeGenOpts. NFC.Alexey Samsonov2014-10-152-3/+3
| | | | | | | | After http://reviews.llvm.org/D5687 is submitted, we will need SanitizerBlacklist before the CodeGen phase, so make it a LangOpt (as it will actually affect ABI / class layout). llvm-svn: 219842
* Move SanitizerBlacklist to clangBasic. NFC.Alexey Samsonov2014-10-154-101/+1
| | | | | | | | | | | | This change moves SanitizerBlacklist.h from lib/CodeGen to public Clang headers in include/clang/Basic. SanitizerBlacklist is currently only used in CodeGen to decide which functions/modules should be instrumented, but this will soon change as ASan will optionally modify class layouts during AST construction (http://reviews.llvm.org/D5687). We need blacklist machinery to be available at this point. llvm-svn: 219840
* Don't use a global_ctors comdat for globals that aren't externally visibleReid Kleckner2014-10-151-9/+9
| | | | | | | | In particular, if you have two identical templates in different TUs in anonymous namespaces, we would use the same global_ctors comdat key for both. As a result, only one would be run. llvm-svn: 219806
* CodeGen: Cleanup CGRecordLowering::lowerUnion a littleDavid Majnemer2014-10-151-7/+7
| | | | | | Remove some duplicated state, no functionality change intended. llvm-svn: 219805
* CodeGen: Use the initing member's type for a union's storage type more oftenDavid Majnemer2014-10-151-1/+16
| | | | | | | | | | Unions are initialized with the default initialization of their first named member. If that member is not zero initialized, then we should prefer that member's type. Otherwise, we might try to make an otherwise unsuitable type (like an array) which we cannot easily initialize with a pointer to member. llvm-svn: 219781
* CodeGen: Fix a typo in a commentDavid Majnemer2014-10-151-1/+1
| | | | | | No functionality change intended. llvm-svn: 219780
* MS ABI: Use the correct this arg when generating implicit array copy ctorDavid Majnemer2014-10-151-3/+2
| | | | | | | We assumed the last argument of the copy constructor was the this pointer. However, this is not the case under the MS ABI. llvm-svn: 219775
* DebugInfo: Lazily built static member variable declarations should use the ↵David Blaikie2014-10-141-0/+1
| | | | | | | | | | | | | | canonical declaration for line/file information. When lazily constructing static member variable declarations (when the vtable optimization fires and the definition of the type is omitted (or built later, lazily), but the out of line definition of the static member is provided and must be described in debug info) ensure we use the canonical declaration when computing the file, line, etc for that declaration (rather than the definition, which is also a declaration, but not the canonical one). llvm-svn: 219736
* Formatting for prior commitDavid Blaikie2014-10-141-4/+5
| | | | llvm-svn: 219692
* DebugInfo: Don't leak location information from one function into the ↵David Blaikie2014-10-142-5/+8
| | | | | | | | | | | | | | | | | | | | | | prologue of the next function. CodeGenFunction objects aren't really designed to be reused for more than one function, and doing so can leak debug info location information from one function into the prologue of the next. Add an assertion in to catch reuses of CodeGenFunction, which surprisingly only caught the ObjC atomic getter/setter cases. Fix those and add a test to demonstrate the issue. The test is a bit slim, because we're just testing for the absence of a debug location on the prologue instructions, which by itself probably wouldn't be the end of the world - but the particular debug location that was ending up there was for the previous function's last instruction. This produced debug info for another function within this function, which is something I'm trying to remove all cases of as its a substantial source of bugs, especially around inlining (see r219215). llvm-svn: 219690
* Sanitize upcasts and conversion to virtual base.Alexey Samsonov2014-10-134-23/+43
| | | | | | | | | | | This change adds UBSan check to upcasts. Namely, when we perform derived-to-base conversion, we: 1) check that the pointer-to-derived has suitable alignment and underlying storage, if this pointer is non-null. 2) if vptr-sanitizer is enabled, and we perform conversion to virtual base, we check that pointer-to-derived has a matching vptr. llvm-svn: 219642
* [OPENMP] Codegen for 'num_threads' clause in 'parallel' directive.Alexey Bataev2014-10-133-7/+54
| | | | | | | This patch generates call to "kmpc_push_num_threads(ident_t *loc, kmp_int32 global_tid, kmp_int32 num_threads);" library function before calling "kmpc_fork_call" each time there is an associated "num_threads" clause in the "omp parallel" directive. Differential Revision: http://reviews.llvm.org/D5145 llvm-svn: 219599
* [OPENMP] Codegen for 'if' clause in 'parallel' directive.Alexey Bataev2014-10-133-7/+155
| | | | | | | | | | | | | | | | | | | | | Adds codegen for 'if' clause. Currently only for 'if' clause used with the 'parallel' directive. If condition evaluates to true, the code executes parallel version of the code by calling __kmpc_fork_call(loc, 1, microtask, captured_struct/*context*/), where loc - debug location, 1 - number of additional parameters after "microtask" argument, microtask - is outlined finction for the code associated with the 'parallel' directive, captured_struct - list of variables captured in this outlined function. If condition evaluates to false, the code executes serial version of the code by executing the following code: global_thread_id.addr = alloca i32 store i32 global_thread_id, global_thread_id.addr zero.addr = alloca i32 store i32 0, zero.addr kmpc_serialized_parallel(loc, global_thread_id); microtask(global_thread_id.addr, zero.addr, captured_struct/*context*/); kmpc_end_serialized_parallel(loc, global_thread_id); Where loc - debug location, global_thread_id - global thread id, returned by __kmpc_global_thread_num() call or passed as a first parameter in microtask() call, global_thread_id.addr - address of the variable, where stored global_thread_id value, zero.addr - implicit bound thread id (should be set to 0 for serial call), microtask() and captured_struct are the same as in parallel call. Also this patch checks if the condition is constant and if it is constant it evaluates its value and then generates either parallel version of the code (if the condition evaluates to true), or the serial version of the code (if the condition evaluates to false). Differential Revision: http://reviews.llvm.org/D4716 llvm-svn: 219597
* Allow constant expressions in pragma loop hints.Tyler Nowicki2014-10-121-2/+9
| | | | | | | | Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1). Reviewed by Richard Smith llvm-svn: 219589
* CodeGen: Strip qualifiers from qualified array types in catchesDavid Majnemer2014-10-121-2/+3
| | | | | | | | | While we ran getUnqualifiedType over the catch type, it isn't enough for array types. Use getUnqualifiedArrayType instead. This fixes PR21252. llvm-svn: 219582
* Suppress a warning about an unused variable in NDEBUG builds.Chandler Carruth2014-10-111-0/+1
| | | | llvm-svn: 219571
* [complex] Teach the other two binary operators on complex numbers (==Chandler Carruth2014-10-111-5/+23
| | | | | | | | | | | | | | | | | and !=) to support mixed complex and real operand types. This requires removing an assert from SemaChecking, and adding support both to the constant evaluator and the code generator to synthesize the imaginary part when needed. This seemed somewhat cleaner than having just the comparison operators force real-to-complex conversions. I've added test cases for these operations. I'm really terrified that there were *no* tests in-tree which exercised this. This turned up when trying to build R after my change to the complex type lowering. llvm-svn: 219570
* [complex] Use the much more powerful EmitCall routine to call libcallsChandler Carruth2014-10-111-17/+1
| | | | | | | | | | | for complex math. This should fix the windows build bots that started having trouble here and generally fix complex libcall emission on targets which use sret for complex data types. It also makes the code a bit simpler (despite calling into a much more complex bucket of code). llvm-svn: 219565
* [complex] Teach Clang to preserve different-type operands to arithmeticChandler Carruth2014-10-111-35/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | operators where one type is a C complex type, and to emit both the efficient and correct implementation for complex arithmetic according to C11 Annex G using this extra information. For both multiply and divide the old code was writing a long-hand reduced version of the math without any of the special handling of inf and NaN recommended by the standard here. Instead of putting more complexity here, this change does what GCC does which is to emit a libcall for the fully general case. However, the old code also failed to do the proper minimization of the set of operations when there was a mixed complex and real operation. In those cases, C provides a spec for much more minimal operations that are valid. Clang now emits the exact suggested operations. This change isn't *just* about performance though, without minimizing these operations, we again lose the correct handling of infinities and NaNs. It is critical that this happen in the frontend based on assymetric type operands to complex math operations. The performance implications of this change aren't trivial either. I've run a set of benchmarks in Eigen, an open source mathematics library that makes heavy use of complex. While a few have slowed down due to the libcall being introduce, most sped up and some by a huge amount: up to 100% and 140%. In order to make all of this work, also match the algorithm in the constant evaluator to the one in the runtime library. Currently it is a broken port of the simplifications from C's Annex G to the long-hand formulation of the algorithm. Splitting this patch up is very hard because none of this works without the AST change to preserve non-complex operands. Sorry for the enormous change. Follow-up changes will include support for sinking the libcalls onto cold paths in common cases and fastmath improvements to allow more aggressive backend folding. Differential Revision: http://reviews.llvm.org/D5698 llvm-svn: 219557
* CodeGen: FieldMemcpyizer didn't handle copies starting inside bitfieldsDavid Majnemer2014-10-101-4/+16
| | | | | | | | | | | | | It's possible to construct cases where the first field we are trying to copy is in the middle of an IR field. In some complicated cases, we would fail to use an appropriate offset inside the object. Earlier builds of clang seemed to miscompile the code by copying an insufficient number of bytes. Up until now, we would assert: the copying offset was insufficiently aligned. This fixes PR21232. llvm-svn: 219524
* Reduce double set lookups. NFC.Benjamin Kramer2014-10-101-2/+1
| | | | llvm-svn: 219504
* Unfriend CGOpenMPRegionInfo so it can go into an anonymous namespace.Benjamin Kramer2014-10-102-8/+4
| | | | | | Also remove some unnecessary virtual keywords. NFC. llvm-svn: 219497
* Fixing the MSVC 2013 build, NFC.Aaron Ballman2014-10-101-0/+3
| | | | llvm-svn: 219491
* Code reformatting and improvement for OpenMP.Alexey Bataev2014-10-104-106/+142
| | | | | | Moved CGOpenMPRegionInfo from CGOpenMPRuntime.h to CGOpenMPRuntime.cpp file and reworked the code for this change. Also added processing of ThreadID variable passed as an argument in outlined functions in parallel and task directives. llvm-svn: 219490
OpenPOWER on IntegriCloud