summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* [MS ABI] Account for the virtual inheritance quirk when manglingDavid Majnemer2015-06-231-28/+6
| | | | | | | | | | | | Virtual inheritance member pointers are always relative to the vbindex, even when the member pointer doesn't point into a virtual base. This is corrected by adjusting the non-virtual offset backwards from the vbptr back to the top of the most derived class. While we performed this adjustment when manifesting member pointers as constants or when performing conversions, we didn't perform the adjustment when mangling them. llvm-svn: 240453
* InstrProf: Fix a crash when an implicit def appears in a macroJustin Bogner2015-06-231-1/+2
| | | | llvm-svn: 240452
* [OPENMP] Initial support for 'depend' clause (4.0).Alexey Bataev2015-06-231-0/+1
| | | | | | Parsing and sema analysis (without support for array sections in arguments) for 'depend' clause (used in 'task' directive, OpenMP 4.0). llvm-svn: 240409
* Update for LLVM api change.Rafael Espindola2015-06-231-1/+4
| | | | llvm-svn: 240406
* Silence VC warning C4715: '`anonymous namespace'::getNativeVectorSizeForA ↵Yaron Keren2015-06-231-0/+1
| | | | | | | | VXABI' : not all control paths return a value. llvm-svn: 240389
* [MS ABI] Rework member pointer conversionDavid Majnemer2015-06-233-65/+271
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Member pointers in the MS ABI are made complicated due to the following: - Virtual methods in the most derived class (MDC) might live in a vftable in a virtual base. - There are four different representations of member pointer: single inheritance, multiple inheritance, virtual inheritance and the "most general" representation. - Bases might have a *more* general representation than classes which derived from them, a most surprising result. We believed that we could treat all member pointers as-if they were a degenerate case of the multiple inheritance model. This fell apart once we realized that implementing standard member pointers using this ABI requires referencing members with a non-zero vbindex. On a bright note, all but the virtual inheritance model operate rather similarly. The virtual inheritance member pointer representation awkwardly requires a virtual base adjustment in order to refer to entities in the MDC. However, the first virtual base might be quite far from the start of the virtual base. This means that we must add a negative non-virtual displacement. However, things get even more complicated. The most general representation interprets vbindex zero differently from the virtual inheritance model: it doesn't reference the vbtable at all. It turns out that this complexity can increase for quite some time: consider a derived to base conversion from the most general model to the multiple inheritance model... To manage this complexity we introduce a concept of "normalized" member pointer which allows us to treat all three models as the most general model. Then we try to figure out how to map this generalized member pointer onto the destination member pointer model. I've done my best to furnish the code with comments explaining why each adjustment is performed. This fixes PR23878. llvm-svn: 240384
* [MS ABI] Refactor member pointer generationDavid Majnemer2015-06-231-28/+75
| | | | | | | | | | | | | | | | The MS ABI has very complicated member pointers. Don't attempt to synthesize the final member pointer ab ovo usque ad mala in one go. Instead, start with a member pointer which points to the declaration in question as-if it's decl context was the target class. Then, utilize our conversion logical to convert it to the target type. This allows us to simplify how we think about member pointers because we don't need to consider non-zero nv adjustments before we even generate the member pointer. Furthermore, it gives our adjustment logic more exposure by utilizing it in a common path. llvm-svn: 240383
* [CodeGen] Rename EmitMemberPointer to EmitMemberFunctionPointerDavid Majnemer2015-06-236-11/+12
| | | | llvm-svn: 240382
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-2231-71/+71
| | | | 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-2231-71/+71
| | | | | | | | | | | | 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
* [Codegen] Don't crash if destructor is not accessible.Davide Italiano2015-06-211-0/+4
| | | | | | | | | | | Testcase provided, in the PR, by Christian Shelton and reduced by David Majnemer. PR: 23584 Differential Revision: http://reviews.llvm.org/D10508 Reviewed by: rnk llvm-svn: 240242
* Avoid clearing an empty PrioritizedCXXGlobalInits, NFCYaron Keren2015-06-201-1/+1
| | | | | | | We already test for PrioritizedCXXGlobalInits being non-empty and process it so it makes sense to clear it only in that if. llvm-svn: 240220
* AMDGPU: Fix places missed in renameMatt Arsenault2015-06-192-22/+22
| | | | llvm-svn: 240148
* [ASan] Initial support for Kernel AddressSanitizerAlexander Potapenko2015-06-195-9/+27
| | | | | | | | | This patch adds initial support for the -fsanitize=kernel-address flag to Clang. Right now it's quite restricted: only out-of-line instrumentation is supported, globals are not instrumented, some GCC kasan flags are not supported. Using this patch I am able to build and boot the KASan tree with LLVMLinux patches from github.com/ramosian-glider/kasan/tree/kasan_llvmlinux. To disable KASan instrumentation for a certain function attribute((no_sanitize("kernel-address"))) can be used. llvm-svn: 240131
* CFI: Implement bitset emission for the Microsoft ABI.Peter Collingbourne2015-06-191-0/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang's control flow integrity implementation works by conceptually attaching "tags" (in the form of bitset entries) to each virtual table, identifying the names of the classes that the virtual table is compatible with. Under the Itanium ABI, it is simple to assign tags to virtual tables; they are simply the address points, which are available via VTableLayout. Because any overridden methods receive an entry in the derived class's virtual table, a check for an overridden method call can always be done by checking the tag of whichever derived class overrode the method call. The Microsoft ABI is a little different, as it does not directly use address points, and overrides in a derived class do not cause new virtual table entries to be added to the derived class; instead, the slot in the base class is reused, and the compiler needs to adjust the this pointer at the call site to (generally) the base class that initially defined the method. After the this pointer has been adjusted, we cannot check for the derived class's tag, as the virtual table may not be compatible with the derived class. So we need to determine which base class we have been adjusted to. Specifically, at each call site, we use ASTRecordLayout to identify the most derived class whose virtual table is laid out at the "this" pointer offset we are using to make the call, and check the virtual table for that tag. Because address point information is unavailable, we "reconstruct" it as follows: any virtual tables we create for a non-derived class receive a tag for that class, and virtual tables for a base class inside a derived class receive a tag for the base class, together with tags for any derived classes which are laid out at the same position as the derived class (and therefore have compatible virtual tables). Differential Revision: http://reviews.llvm.org/D10520 llvm-svn: 240117
* Fix "the the" in comments/documentation/etc.Eric Christopher2015-06-191-1/+1
| | | | llvm-svn: 240110
* Implement diagnostic mode for -fsanitize=cfi*, -fsanitize=cfi-diag.Peter Collingbourne2015-06-198-35/+81
| | | | | | | | | | | | | | | | | This causes programs compiled with this flag to print a diagnostic when a control flow integrity check fails instead of aborting. Diagnostics are printed using UBSan's runtime library. The main motivation of this feature over -fsanitize=vptr is fidelity with the -fsanitize=cfi implementation: the diagnostics are printed under exactly the same conditions as those which would cause -fsanitize=cfi to abort the program. This means that the same restrictions apply regarding compiling all translation units with -fsanitize=cfi, cross-DSO virtual calls are forbidden, etc. Differential Revision: http://reviews.llvm.org/D10268 llvm-svn: 240109
* Introduce -fsanitize-trap= flag.Peter Collingbourne2015-06-181-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined. This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight). Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined. Differential Revision: http://reviews.llvm.org/D10464 llvm-svn: 240105
* [MS ABI] Initialize "most general" member pointers which don't point at a vbaseDavid Majnemer2015-06-181-1/+1
| | | | | | | | | | The most general model has fields for the vbptr offset and the vbindex. Don't initialize the vbptr offset if the vbindex is 0: we aren't referencing an entity from a vbase. Getting this wrong can make member pointer equality fail. llvm-svn: 240043
* [OPENMP] Codegen for 'proc_bind' clause (4.0).Alexey Bataev2015-06-183-0/+57
| | | | | | | Adds emission of the code for 'proc_bind(master|close|spread)' clause: call void @__kmpc_push_proc_bind(<loc>, i32 thread_id, i32 4|3|2) llvm-svn: 240018
* [OPENMP] Support for '#pragma omp taskgroup' directive.Alexey Bataev2015-06-185-2/+62
| | | | | | | | | | | | | Added parsing, sema analysis and codegen for '#pragma omp taskgroup' directive (OpenMP 4.0). The code for directive is generated the following way: #pragma omp taskgroup <body> void __kmpc_taskgroup(<loc>, thread_id); <body> void __kmpc_end_taskgroup(<loc>, thread_id); llvm-svn: 240011
* [OPENMP] Add support for 'omp parallel for' directive.Alexey Bataev2015-06-182-10/+37
| | | | | | Codegen for this directive is a combined codegen for 'omp parallel' region with 'omp for simd' region inside. Clauses are supported. llvm-svn: 240006
* [OPENMP] Add support for 'omp for simd' directive.Alexey Bataev2015-06-182-34/+58
| | | | | | Added codegen for combined 'omp for simd' directives, that is a combination of 'omp for' directive followed by 'omp simd' directive. Includes support for all clauses. llvm-svn: 239990
* Update clang to take into account the changes to personality fnsDavid Majnemer2015-06-171-6/+11
| | | | llvm-svn: 239941
* CodeGen: Factor out some of the bitset entry creation code. NFC.Peter Collingbourne2015-06-173-18/+23
| | | | llvm-svn: 239927
* [OPENMP] Code reformatting for omp simd codegen, NFC.Alexey Bataev2015-06-172-104/+103
| | | | llvm-svn: 239889
* [OPENMP] Supported reduction clause in omp simd construct.Alexey Bataev2015-06-173-3/+20
| | | | | | | | | | | | | | | | The following code is generated for reduction clause within 'omp simd' loop construct: #pragma omp simd reduction(op:var) for (...) <body> alloca priv_var priv_var = <initial reduction value>; <loop_start>: <body> // references to original 'var' are replaced by 'priv_var' <loop_end>: var op= priv_var; llvm-svn: 239881
* Update for llvm api change.Rafael Espindola2015-06-161-2/+2
| | | | llvm-svn: 239859
* [OPENMP] Support lastprivate clause in omp simd directive.Alexey Bataev2015-06-162-19/+33
| | | | | | Added codegen for lastprivate clauses within simd loop-based directives. llvm-svn: 239813
* [OPENMP] Remove last iteration separation for loop-based constructs.Alexey Bataev2015-06-162-16/+7
| | | | | | Previously the last iteration for simd loop-based OpenMP constructs were generated as a separate code. This feature is not required and codegen is simplified. llvm-svn: 239810
* InstrProf: Fix coverage mapping when "if" is a macroJustin Bogner2015-06-161-0/+3
| | | | | | | | | We were propagating the coverage map into the body of an if statement, but not into the condition thereafter. This is fine as long as the two locations are in the same virtual file, but they won't be when the "if" part of the statement is from a macro and the condition is not. llvm-svn: 239803
* Debug Info: Turn on ODR type uniquing for (the C++ part of) Objective-C++.Adrian Prantl2015-06-151-4/+15
| | | | | | rdar://problem/20571359 llvm-svn: 239781
* Protection against stack-based memory corruption errors using SafeStack: ↵Peter Collingbourne2015-06-152-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Clang command line option and function attribute This patch adds the -fsanitize=safe-stack command line argument for clang, which enables the Safe Stack protection (see http://reviews.llvm.org/D6094 for the detailed description of the Safe Stack). This patch is our implementation of the safe stack on top of Clang. The patches make the following changes: - Add -fsanitize=safe-stack and -fno-sanitize=safe-stack options to clang to control safe stack usage (the safe stack is disabled by default). - Add __attribute__((no_sanitize("safe-stack"))) attribute to clang that can be used to disable the safe stack for individual functions even when enabled globally. Original patch by Volodymyr Kuznetsov and others at the Dependable Systems Lab at EPFL; updates and upstreaming by myself. Differential Revision: http://reviews.llvm.org/D6095 llvm-svn: 239762
* This patch implements clang support for the ACLE special register intrinsicsLuke Cheeseman2015-06-151-0/+121
| | | | | | | | | | | | | in section 10.1, __arm_{w,r}sr{,p,64}. This includes arm_acle.h definitions with builtins and codegen to support these, the intrinsics are implemented by generating read/write_register calls which get appropriately lowered in the backend based on the register string provided. SemaChecking is also implemented to fault invalid parameters. Differential Revision: http://reviews.llvm.org/D9697 llvm-svn: 239737
* [CodeGen] Don't evaluate immediate inlineasm arguments using isICE().Ahmed Bougacha2015-06-131-1/+1
| | | | | | | | | | | Instead, just EvaluateAsInt(). Follow-up to r239549: rsmith points out that isICE() is expensive; seems like it's not the right concept anyway, as it fails on `static const' in C, and will actually trigger the assert below on: test/Sema/inline-asm-validate-x86.c llvm-svn: 239651
* [CodeGen] Use IRBuilder to create llvm.lifetime intrinsics.Alexey Samsonov2015-06-121-9/+6
| | | | | | | | | | | | | | | | | | | | Summary: In addition to easier syntax, IRBuilder makes sure to set correct debug locations for newly added instructions (bitcast and llvm.lifetime itself). This restores the original behavior, which was modified by r234581 (reapplied as r235553). Extend one of the tests to check for debug locations. Test Plan: regression test suite Reviewers: aadg, dblaikie Subscribers: cfe-commits, majnemer Differential Revision: http://reviews.llvm.org/D10418 llvm-svn: 239643
* [CGCall] Fix potential invalid iterator decrement in ↵Alexey Samsonov2015-06-121-5/+4
| | | | | | | | | | | findDominatingStoreToReturnValue. If llvm.lifetime.end turns out to be the first instruction in the last basic block, we can decrement the iterator twice, going past rend. At the moment, this can never happen because llvm.lifetime.end always goes immediately after bitcast, but relying on this is very brittle. llvm-svn: 239638
* push_back() loop -> append() for random access iterators.Benjamin Kramer2015-06-121-7/+3
| | | | | | | append will resize the vector to the optimal size. No functional change intended. llvm-svn: 239607
* Revert commit r239481 as it is dependent on reverted llvm commit r239480.Teresa Johnson2015-06-121-1/+0
| | | | llvm-svn: 239588
* Handle fpmath= in the target attribute.Eric Christopher2015-06-121-0/+5
| | | | | | | | | | Right now we're ignoring the fpmath attribute since there's no backend support for a feature like this and to do so would require checking the validity of the strings and doing general subtarget feature parsing of valid and invalid features with the target attribute feature. llvm-svn: 239582
* Handle -mno-<feature> in target attribute strings by replacing theEric Christopher2015-06-121-2/+4
| | | | | | | -mno- with a -<feature> to match how we handle this in the rest of the frontend. llvm-svn: 239581
* Add support for tune= to the target attribute support by ignoring it.Eric Christopher2015-06-121-0/+3
| | | | | | | We don't currently support the -mtune option in any useful way so ignoring the annotation is fine. llvm-svn: 239580
* Add support for the the target attribute.Eric Christopher2015-06-121-11/+39
| | | | | | | | | | | | | | | Modeled after the gcc attribute of the same name, this feature allows source level annotations to correspond to backend code generation. In llvm particular parlance, this allows the adding of subtarget features and changing the cpu for a particular function based on source level hints. This has been added into the existing support for function level attributes without particular verification for any target outside of whether or not the backend will support the features/cpu given (similar to section, etc). llvm-svn: 239579
* [IRGen] Fix the MSVC2013 buildDavid Majnemer2015-06-121-1/+2
| | | | llvm-svn: 239576
* Add assume_safety option for pragma loop vectorize and interleave.Tyler Nowicki2015-06-113-6/+37
| | | | | | | | Specifying #pragma clang loop vectorize(assume_safety) on a loop adds the mem.parallel_loop_access metadata to each load/store operation in the loop. This metadata tells loop access analysis (LAA) to skip memory dependency checking. llvm-svn: 239572
* [CodeGen] Emit Constants for immediate inlineasm arguments.Ahmed Bougacha2015-06-111-0/+10
| | | | | | | | | | | | | | | | | For inline assembly immediate constraints, we currently always use EmitScalarExpr, instead of directly emitting the constant. When the overflow sanitizer is enabled, this generates overflow intrinsics instead of constants. Instead, emit a constant for constraints that either require an immediate (e.g. 'I' on X86), or only accepts constants (immediate or symbolic; i.e., don't accept registers or memory). Fixes PR19763. Differential Revision: http://reviews.llvm.org/D10255 llvm-svn: 239549
* add the -mrecip driver flag and process its options (3rd try)Sanjay Patel2015-06-111-0/+3
| | | | | | | | | | | | | | | | | | | The 1st and 2nd tries to land this (r238055, r238851) were reverted due to bot failures caused by the LLVM part of the patch. That was hopefully fixed after r239001. This is the front-end counterpart to D8982. The -mrecip option interface is based on maintaining compatibility with gcc: https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#index-mrecip_003dopt-1627 https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/RS_002f6000-and-PowerPC-Options.html#index-mrecip-2289 ...while adding more functionality (allowing users to specify the number of refinement steps for each estimate type). Differential Revision: http://reviews.llvm.org/D8989 llvm-svn: 239536
* C++11 rangify several loops.Yaron Keren2015-06-111-36/+21
| | | | llvm-svn: 239528
OpenPOWER on IntegriCloud