summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CodeGenFunction.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [NFC] Fix usage of Builder.insert(new Bitcast...)in CodeGenFunctionErich Keane2018-12-181-1/+1
| | | | | | | | | | | | This is exactly a "CreateBitCast", so refactor this to get rid of a 'new'. Note that this slightly changes the test, as the Builder is now seemingly smart enough to fold one of the bitcasts into the annotation call. Change-Id: I1733fb1fdf91f5c9d88651067130b9a4e7b5ab67 llvm-svn: 349506
* Remove unused Args parameter from EmitFunctionBody, NFCReid Kleckner2018-12-131-3/+2
| | | | llvm-svn: 349001
* Teach __builtin_unpredictable to work through implicit casts.Erich Keane2018-12-121-1/+1
| | | | | | | | | The __builtin_unpredictable implementation is confused by any implicit casts, which happen in C++. This patch strips those off so that if/switch statements now work with it in C++. Change-Id: I73c3bf4f1775cd906703880944f4fcdc29fffb0a llvm-svn: 348969
* Move CodeGenOptions from Frontend to BasicRichard Trieu2018-12-111-1/+1
| | | | | | Basic uses CodeGenOptions and should not depend on Frontend. llvm-svn: 348827
* Fix thunks returning memptrs via sret by emitting also scalar return values ↵Hans Wennborg2018-12-071-3/+2
| | | | | | | | | | | | | | | | | | | directly in sret slot (PR39901) Thunks that return member pointers via sret are broken due to using temporary storage for the return value on the stack and then passing that pointer to a tail call, violating the rule that a tail call can't access allocas in the caller (see bug). Since r90526, we put aggregate return values directly in the sret slot, but this doesn't apply to member pointers which are considered scalar. Unless I'm missing something subtle, we should be able to always use the sret slot directly for indirect return values. Differential revision: https://reviews.llvm.org/D55371 llvm-svn: 348569
* Remove CodeGen dependencies on Sema.Richard Trieu2018-12-061-1/+1
| | | | | | | Move diagnostics from Sema to Frontend (or Common) so that CodeGen no longer needs to include the Sema diagnostic IDs. llvm-svn: 348458
* Revert "Revert r347417 "Re-Reinstate 347294 with a fix for the failures.""Fangrui Song2018-11-301-2/+3
| | | | | | | | | It seems the two failing tests can be simply fixed after r348037 Fix 3 cases in Analysis/builtin-functions.cpp Delete the bad CodeGen/builtin-constant-p.c for now llvm-svn: 348053
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Fangrui Song2018-11-301-3/+2
| | | | | | | | | | Kept the "indirect_builtin_constant_p" test case in test/SemaCXX/constant-expression-cxx1y.cpp while we are investigating why the following snippet fails: extern char extern_var; struct { int a; } a = {__builtin_constant_p(extern_var)}; llvm-svn: 348039
* Re-commit r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-281-2/+3
| | | | | | | This was reverted in r347656 due to me thinking it caused a miscompile of Chromium. Turns out it was the Chromium code that was broken. llvm-svn: 347756
* Revert r347417 "Re-Reinstate 347294 with a fix for the failures."Hans Wennborg2018-11-271-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused a miscompile in Chrome (see crbug.com/908372) that's illustrated by this small reduction: static bool f(int *a, int *b) { return !__builtin_constant_p(b - a) || (!(b - a)); } int arr[] = {1,2,3}; bool g() { return f(arr, arr + 3); } $ clang -O2 -S -emit-llvm a.cc -o - g() should return true, but after r347417 it became false for some reason. This also reverts the follow-up commits. r347417: > Re-Reinstate 347294 with a fix for the failures. > > Don't try to emit a scalar expression for a non-scalar argument to > __builtin_constant_p(). > > Third time's a charm! r347446: > The result of is.constant() is unsigned. r347480: > A __builtin_constant_p() returns 0 with a function type. r347512: > isEvaluatable() implies a constant context. > > Assume that we're in a constant context if we're asking if the expression can > be compiled into a constant initializer. This fixes the issue where a > __builtin_constant_p() in a compound literal was diagnosed as not being > constant, even though it's always possible to convert the builtin into a > constant. r347531: > A "constexpr" is evaluated in a constant context. Make sure this is reflected > if a __builtin_constant_p() is a part of a constexpr. llvm-svn: 347656
* Re-Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-211-2/+3
| | | | | | | | | Don't try to emit a scalar expression for a non-scalar argument to __builtin_constant_p(). Third time's a charm! llvm-svn: 347417
* Revert r347364 again, the fix was incomplete.Nico Weber2018-11-211-3/+2
| | | | llvm-svn: 347389
* Reinstate 347294 with a fix for the failures.Bill Wendling2018-11-201-2/+3
| | | | | | | EvaluateAsInt() is sometimes called in a constant context. When that's the case, we need to specify it as so. llvm-svn: 347364
* [NFC] Move storage of dispatch-version to GlobalDeclErich Keane2018-11-131-1/+1
| | | | | | | | | | | | | | | | | | | As suggested by Richard Smith, and initially put up for review here: https://reviews.llvm.org/D53341, this patch removes a hack that was used to ensure that proper target-feature lists were used when emitting cpu-dispatch (and eventually, target-clones) implementations. As a part of this, the GlobalDecl object is proliferated to a bunch more locations. Originally, this was put up for review (see above) to get acceptance on the approach, though discussion with Richard in San Diego showed he approved of the approach taken here. Thus, I believe this is acceptable for Review-After-commit Differential Revision: https://reviews.llvm.org/D53341 Change-Id: I0a0bd673340d334d93feac789d653e03d9f6b1d5 llvm-svn: 346757
* Implement Function Multiversioning for Non-ELF Systems.Erich Keane2018-10-251-3/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | Similar to how ICC handles CPU-Dispatch on Windows, this patch uses the resolver function directly to forward the call to the proper function. This is not nearly as efficient as IFuncs of course, but is still quite useful for large functions specifically developed for certain processors. This is unfortunately still limited to x86, since it depends on __builtin_cpu_supports and __builtin_cpu_is, which are x86 builtins. The naming for the resolver/forwarding function for cpu-dispatch was taken from ICC's implementation, which uses the unmodified name for this (no mangling additions). This is possible, since cpu-dispatch uses '.A' for the 'default' version. In 'target' multiversioning, this function keeps the '.resolver' extension in order to keep the default function keeping the default mangling. Change-Id: I4731555a39be26c7ad59a2d8fda6fa1a50f73284 Differential Revision: https://reviews.llvm.org/D53586 llvm-svn: 345298
* [CodeGen] Always emit the 'min-legal-vector-width' attribute even when the ↵Craig Topper2018-10-251-3/+1
| | | | | | | | value is 0. The X86 backend will need to see the attribute to make decisions. If it isn't present the backend will have to assume large vectors may be present. llvm-svn: 345237
* [CodeGen] Update min-legal-vector width based on function argument and ↵Craig Topper2018-10-241-1/+18
| | | | | | | | | | | | return types This is a continuation of my patches to inform the X86 backend about what the largest IR types are in the function so that we can restrict the backend type legalizer to prevent 512-bit vectors on SKX when -mprefer-vector-width=256 is specified if no explicit 512 bit vectors were specified by the user. This patch updates the vector width based on the argument and return types of the current function and from the types of any functions it calls. This is intended to make sure the backend type legalizer doesn't disturb any types that are required for ABI. Differential Revision: https://reviews.llvm.org/D52441 llvm-svn: 345168
* Use llvm::{all,any,none}_of instead std::{all,any,none}_of. NFCFangrui Song2018-10-201-8/+7
| | | | llvm-svn: 344859
* [CodeGen] Revert commit https://reviews.llvm.org/rL342717Calixte Denizet2018-09-241-3/+3
| | | | llvm-svn: 342912
* [CodeGen] Add to emitted DebugLoc information about coverage when it's requiredCalixte Denizet2018-09-211-3/+3
| | | | | | | | | | | | | | | | | | | | Summary: Some lines have a hit counter where they should not have one. Cleanup stuff is located to the last line of the body which is most of the time a '}'. And Exception stuff is added at the beginning of a function and at the end (represented by '{' and '}'). So in such cases, the DebugLoc used in GCOVProfiling.cpp must be marked as not covered. This patch is a followup of https://reviews.llvm.org/D49915. Tests in projects/compiler_rt are fixed by: https://reviews.llvm.org/D49917 Reviewers: marco-c, davidxl Reviewed By: marco-c Subscribers: dblaikie, cfe-commits, sylvestre.ledru Differential Revision: https://reviews.llvm.org/D49916 llvm-svn: 342717
* [XRay][clang] Emit "never-instrument" attributeDean Michael Berris2018-09-141-12/+12
| | | | | | | | | | | | | | | | | | | | | | | Summary: Before this change, we only emit the XRay attributes in LLVM IR when the -fxray-instrument flag is provided. This may cause issues with thinlto when the final binary is being built/linked with -fxray-instrument, and the constitutent LLVM IR gets re-lowered with xray instrumentation. With this change, we can honour the "never-instrument "attributes provided in the source code and preserve those in the IR. This way, even in thinlto builds, we retain the attributes which say whether functions should never be XRay instrumented. This change addresses llvm.org/PR38922. Reviewers: mboerger, eizan Subscribers: mehdi_amini, dexonsmith, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D52015 llvm-svn: 342200
* [NFC]Refactor MultiVersion Resolver Emission to combine typesErich Keane2018-09-131-59/+21
| | | | | | | | | Previously, both types (plus the future target-clones) of multiversioning had a separate ResolverOption structure and emission function. This patch combines the two, at the expense of a slightly more expensive sorting function. llvm-svn: 342152
* [MSan] add KMSAN support to Clang driverAlexander Potapenko2018-09-071-1/+1
| | | | | | | | | | | | | | | Boilerplate code for using KMSAN instrumentation in Clang. We add a new command line flag, -fsanitize=kernel-memory, with a corresponding SanitizerKind::KernelMemory, which, along with SanitizerKind::Memory, maps to the memory_sanitizer feature. KMSAN is only supported on x86_64 Linux. It's incompatible with other sanitizers, but supports code coverage instrumentation. llvm-svn: 341641
* [CodeGen] Implicitly set stackrealign on the main function, if custom stack ↵Martin Storsjo2018-08-211-0/+7
| | | | | | | | | | | | | | | | | | | | | alignment is used If using a custom stack alignment, one is expected to make sure that all callers provide such alignment, or realign the stack in all entry points (and callbacks). Despite this, the compiler can assume that the main function will need realignment in these cases, since the startup routines calling the main function most probably won't provide the custom alignment. This matches what GCC does in similar cases; if compiling with -mincoming-stack-boundary=X -mpreferred-stack-boundary=X, GCC normally assumes such alignment on entry to a function, but specifically for the main function still does realignment. Differential Revision: https://reviews.llvm.org/D51026 llvm-svn: 340334
* [CodeGen] Merge equivalent block copy/helper functions.Akira Hatanaka2018-08-101-7/+5
| | | | | | | | | | | | | | | | | | | | | | | Clang generates copy and dispose helper functions for each block literal on the stack. Often these functions are equivalent for different blocks. This commit makes changes to merge equivalent copy and dispose helper functions and reduce code size. To enable merging equivalent copy/dispose functions, the captured object infomation is encoded into the helper function name. This allows IRGen to check whether an equivalent helper function has already been emitted and reuse the function instead of generating a new helper function whenever a block is defined. In addition, the helper functions are marked as linkonce_odr to enable merging helper functions that have the same name across translation units and marked as unnamed_addr to enable the linker's deduplication pass to merge functions that have different names but the same content. rdar://problem/42640608 Differential Revision: https://reviews.llvm.org/D50152 llvm-svn: 339438
* Port getLocStart -> getBeginLocStephen Kelly2018-08-091-5/+4
| | | | | | | | | | Reviewers: teemperor! Subscribers: jholewinski, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D50350 llvm-svn: 339385
* Implement cpu_dispatch/cpu_specific MultiversioningErich Keane2018-07-201-6/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As documented here: https://software.intel.com/en-us/node/682969 and https://software.intel.com/en-us/node/523346. cpu_dispatch multiversioning is an ICC feature that provides for function multiversioning. This feature is implemented with two attributes: First, cpu_specific, which specifies the individual function versions. Second, cpu_dispatch, which specifies the location of the resolver function and the list of resolvable functions. This is valuable since it provides a mechanism where the resolver's TU can be specified in one location, and the individual implementions each in their own translation units. The goal of this patch is to be source-compatible with ICC, so this implementation diverges from the ICC implementation in a few ways: 1- Linux x86/64 only: This implementation uses ifuncs in order to properly dispatch functions. This is is a valuable performance benefit over the ICC implementation. A future patch will be provided to enable this feature on Windows, but it will obviously more closely fit ICC's implementation. 2- CPU Identification functions: ICC uses a set of custom functions to identify the feature list of the host processor. This patch uses the cpu_supports functionality in order to better align with 'target' multiversioning. 1- cpu_dispatch function def/decl: ICC's cpu_dispatch requires that the function marked cpu_dispatch be an empty definition. This patch supports that as well, however declarations are also permitted, since the linker will solve the issue of multiple emissions. Differential Revision: https://reviews.llvm.org/D47474 llvm-svn: 337552
* [NFC] Switch CodeGenFunction to use value init instead of member init listsErich Keane2018-07-101-19/+3
| | | | | | | | | The member init list for the sole constructor for CodeGenFunction has gotten out of hand, so this patch moves the non-parameter-dependent initializations into the member value inits. Note: This is what was intended to be committed in r336726 llvm-svn: 336729
* Revert -r336726, which included more files than intended.Erich Keane2018-07-101-3/+19
| | | | llvm-svn: 336727
* [NFC] Switch CodeGenFunction to use value init instead of member init listsErich Keane2018-07-101-19/+3
| | | | | | | | The member init list for the sole constructor for CodeGenFunction has gotten out of hand, so this patch moves the non-parameter-dependent initializations into the member value inits. llvm-svn: 336726
* [Builtins][Attributes][X86] Tag all X86 builtins with their required vector ↵Craig Topper2018-07-091-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | width. Add a min_vector_width function attribute and tag all x86 instrinsics with it This is part of an ongoing attempt at making 512 bit vectors illegal in the X86 backend type legalizer due to CPU frequency penalties associated with wide vectors on Skylake Server CPUs. We want the loop vectorizer to be able to emit IR containing wide vectors as intermediate operations in vectorized code and allow these wide vectors to be legalized to 256 bits by the X86 backend even though we are targetting a CPU that supports 512 bit vectors. This is similar to what happens with an AVX2 CPU, the vectorizer can emit wide vectors and the backend will split them. We want this splitting behavior, but still be able to use new Skylake instructions that work on 256-bit vectors and support things like masking and gather/scatter. Of course if the user uses explicit vector code in their source code we need to not split those operations. Especially if they have used any of the 512-bit vector intrinsics from immintrin.h. And we need to make it so that merely using the intrinsics produces the expected code in order to be backwards compatible. To support this goal, this patch adds a new IR function attribute "min-legal-vector-width" that can indicate the need for a minimum vector width to be legal in the backend. We need to ensure this attribute is set to the largest vector width needed by any intrinsics from immintrin.h that the function uses. The inliner will be reponsible for merging this attribute when a function is inlined. We may also need a way to limit inlining in the future as well, but we can discuss that in the future. To make things more complicated, there are two different ways intrinsics are implemented in immintrin.h. Either as an always_inline function containing calls to builtins(can be target specific or target independent) or vector extension code. Or as a macro wrapper around a taget specific builtin. I believe I've removed all cases where the macro was around a target independent builtin. To support the always_inline function case this patch adds attribute((min_vector_width(128))) that can be used to tag these functions with their vector width. All x86 intrinsic functions that operate on vectors have been tagged with this attribute. To support the macro case, all x86 specific builtins have also been tagged with the vector width that they require. Use of any builtin with this property will implicitly increase the min_vector_width of the function that calls it. I've done this as a new property in the attribute string for the builtin rather than basing it on the type string so that we can opt into it on a per builtin basis and avoid any impact to target independent builtins. There will be future work to support vectors passed as function arguments and supporting inline assembly. And whatever else we can find that isn't covered by this patch. Special thanks to Chandler who suggested this direction and reviewed a preview version of this patch. And thanks to Eric Christopher who has had many conversations with me about this issue. Differential Revision: https://reviews.llvm.org/D48617 llvm-svn: 336583
* [CodeGen] Improve diagnostics related to target attributesGabor Buella2018-06-071-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When requirement imposed by __target__ attributes on functions are not satisfied, prefer printing those requirements, which are explicitly mentioned in the attributes. This makes such messages more useful, e.g. printing avx512f instead of avx2 in the following scenario: ``` $ cat foo.c static inline void __attribute__((__always_inline__, __target__("avx512f"))) x(void) { } int main(void) { x(); } $ clang foo.c foo.c:7:2: error: always_inline function 'x' requires target feature 'avx2', but would be inlined into function 'main' that is compiled without support for 'avx2' x(); ^ 1 error generated. ``` bugzilla: https://bugs.llvm.org/show_bug.cgi?id=37338 Reviewers: craig.topper, echristo, dblaikie Reviewed By: craig.topper, echristo Differential Revision: https://reviews.llvm.org/D46541 llvm-svn: 334174
* [CodeGenFunction] Use the StringRef::split function that takes a char ↵Craig Topper2018-05-031-2/+2
| | | | | | | | separator instead of StringRef separator. NFC The char separator version should be a little better optimized. llvm-svn: 331482
* [XRay] Add clang builtin for xray typed events.Keith Wyss2018-04-171-1/+8
| | | | | | | | | | | | | | | | | | | Summary: A clang builtin for xray typed events. Differs from __xray_customevent(...) by the presence of a type tag that is vended by compiler-rt in typical usage. This allows xray handlers to expand logged events with their type description and plugins to process traced events based on type. This change depends on D45633 for the intrinsic definition. Reviewers: dberris, pelikan, rnk, eizan Subscribers: cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D45716 llvm-svn: 330220
* [CodeView] Initial support for emitting S_THUNK32 symbols for compiler...Brock Wyma2018-04-161-1/+2
| | | | | | | | | | | When emitting CodeView debug information, compiler-generated thunk routines should be emitted using S_THUNK32 symbols instead of S_GPROC32_ID symbols so Visual Studio can properly step into the user code. This initial support only handles standard thunk ordinals. Differential Revision: https://reviews.llvm.org/D43838 llvm-svn: 330132
* hwasan: add -fsanitize=kernel-hwaddress flagAndrey Konovalov2018-04-131-1/+5
| | | | | | | | | This patch adds -fsanitize=kernel-hwaddress flag, that essentially enables -hwasan-kernel=1 -hwasan-recover=1 -hwasan-match-all-tag=0xff. Differential Revision: https://reviews.llvm.org/D45046 llvm-svn: 330044
* [XRay][clang] Add flag to choose instrumentation bundlesDean Michael Berris2018-04-131-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change addresses http://llvm.org/PR36926 by allowing users to pick which instrumentation bundles to use, when instrumenting with XRay. In particular, the flag `-fxray-instrumentation-bundle=` has four valid values: - `all`: the default, emits all instrumentation kinds - `none`: equivalent to -fnoxray-instrument - `function`: emits the entry/exit instrumentation - `custom`: emits the custom event instrumentation These can be combined either as comma-separated values, or as repeated flag values. Reviewers: echristo, kpw, eizan, pelikan Reviewed By: pelikan Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D44970 llvm-svn: 329985
* asan: kernel: make no_sanitize("address") attribute work with ↵Vitaly Buka2018-04-091-2/+8
| | | | | | | | | | | | | | | | | -fsanitize=kernel-address Summary: Right now to disable -fsanitize=kernel-address instrumentation, one needs to use no_sanitize("kernel-address"). Make either no_sanitize("address") or no_sanitize("kernel-address") disable both ASan and KASan instrumentation. Also remove redundant test. Patch by Andrey Konovalov Reviewers: eugenis, kcc, glider, dvyukov, vitalybuka Reviewed By: eugenis, vitalybuka Differential Revision: https://reviews.llvm.org/D44981 llvm-svn: 329612
* Add the -fsanitize=shadow-call-stack flagVlad Tsyrklevich2018-04-031-0/+2
| | | | | | | | | | | | | | | | | Summary: Add support for the -fsanitize=shadow-call-stack flag which causes clang to add ShadowCallStack attribute to functions compiled with that flag enabled. Reviewers: pcc, kcc Reviewed By: pcc, kcc Subscribers: cryptoad, cfe-commits, kcc Differential Revision: https://reviews.llvm.org/D44801 llvm-svn: 329122
* [libFuzzer] Use OptForFuzzing attribute with -fsanitize=fuzzer.Matt Morehouse2018-03-231-0/+4
| | | | | | | | | | | | | | | | | | | Summary: Disables certain CMP optimizations to improve fuzzing signal under -O1 and -O2. Switches all fuzzer tests to -O2 except for a few leak tests where the leak is optimized out under -O2. Reviewers: kcc, vitalybuka Reviewed By: vitalybuka Subscribers: cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D44798 llvm-svn: 328384
* [OpenMP] Add OpenMP data sharing infrastructure using global memoryGheorghe-Teodor Bercea2018-03-141-0/+5
| | | | | | | | | | | | | | | | | Summary: This patch handles the Clang code generation phase for the OpenMP data sharing infrastructure. TODO: add a more detailed description. Reviewers: ABataev, carlo.bertolli, caomhin, hfinkel, Hahnfeld Reviewed By: ABataev Subscribers: jholewinski, guansong, cfe-commits Differential Revision: https://reviews.llvm.org/D43660 llvm-svn: 327513
* Do not generate calls to fentry with __attribute__((no_instrument_function))Manoj Gupta2018-03-021-4/+6
| | | | | | | | | | | | | | | | | | | Summary: Currently only calls to mcount were suppressed with no_instrument_function attribute. Linux kernel requires that calls to fentry should also not be generated. This is an extended fix for PR PR33515. Reviewers: hfinkel, rengolin, srhines, rnk, rsmith, rjmccall, hans Reviewed By: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43995 llvm-svn: 326639
* Remove redundant casts. NFCGeorge Burgess IV2018-03-011-2/+1
| | | | | | | | | | | | | | | | | | | So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in LLVM and other subprojects when I find time. Because of the volume of changes, I explicitly avoided making any change that wasn't highly local and obviously correct to me (e.g. we still have a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading is a thing and the cast<Bar> did actually change the type -- just up the class hierarchy). I also tried to leave the types we were cast<>ing to somewhere nearby, in cases where it wasn't locally obvious what we were dealing with before. llvm-svn: 326416
* Recommit rL323952: [DebugInfo] Enable debug information for C99 VLA types.Sander de Smalen2018-02-031-11/+22
| | | | | | Fixed build issue when building with g++-4.8 (specialization after instantiation). llvm-svn: 324173
* Reverting patch rL323952 due to build errors that ISander de Smalen2018-02-011-22/+11
| | | | | | haven't encountered in local builds. llvm-svn: 323956
* [DebugInfo] Enable debug information for C99 VLA typesSander de Smalen2018-02-011-11/+22
| | | | | | | | | | | | | | | | | | | | | Summary: This patch enables debugging of C99 VLA types by generating more precise LLVM Debug metadata, using the extended DISubrange 'count' field that takes a DIVariable. This should implement: Bug 30553: Debug info generated for arrays is not what GDB expects (not as good as GCC's) https://bugs.llvm.org/show_bug.cgi?id=30553 Reviewers: echristo, aprantl, dexonsmith, clayborg, pcc, kristof.beyls, dblaikie Reviewed By: aprantl Subscribers: jholewinski, schweitz, davide, fhahn, JDevlieghere, cfe-commits Differential Revision: https://reviews.llvm.org/D41698 llvm-svn: 323952
* Allocate and access NormalCleanupDest with the natural alignment of i32.John McCall2018-01-121-4/+5
| | | | | | | | | This alignment can be less than 4 on certain embedded targets, which may not even be able to deal with 4-byte alignment on the stack. Patch by Jacob Young! llvm-svn: 322406
* Added Control Flow Protection FlagOren Ben Simhon2018-01-091-1/+2
| | | | | | | | | | Cf-protection is a target independent flag that instructs the back-end to instrument control flow mechanisms like: Branch, Return, etc. For example in X86 this flag will be used to instrument Indirect Branch Tracking instructions. Differential Revision: https://reviews.llvm.org/D40478 Change-Id: I5126e766c0e6b84118cae0ee8a20fe78cc373dea llvm-svn: 322063
* Implement Attribute Target MultiVersioningErich Keane2018-01-081-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC's attribute 'target', in addition to being an optimization hint, also allows function multiversioning. We currently have the former implemented, this is the latter's implementation. This works by enabling functions with the same name/signature to coexist, so that they can all be emitted. Multiversion state is stored in the FunctionDecl itself, and SemaDecl manages the definitions. Note that it ends up having to permit redefinition of functions so that they can all be emitted. Additionally, all versions of the function must be emitted, so this also manages that. Note that this includes some additional rules that GCC does not, since defining something as a MultiVersion function after a usage has been made illegal. The only 'history rewriting' that happens is if a function is emitted before it has been converted to a multiversion'ed function, at which point its name needs to be changed. Function templates and virtual functions are NOT yet supported (not supported in GCC either). Additionally, constructors/destructors are disallowed, but the former is planned. llvm-svn: 322028
* No -fsanitize=function warning when calling noexcept function through ↵Stephan Bergmann2018-01-051-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | non-noexcept pointer in C++17 As discussed in the mail thread <https://groups.google.com/a/isocpp.org/forum/ #!topic/std-discussion/T64_dW3WKUk> "Calling noexcept function throug non- noexcept pointer is undefined behavior?", such a call should not be UB. However, Clang currently warns about it. This change removes exception specifications from the function types recorded for -fsanitize=function, both in the functions themselves and at the call sites. That means that calling a non-noexcept function through a noexcept pointer will also not be flagged as UB. In the review of this change, that was deemed acceptable, at least for now. (See the "TODO" in compiler-rt test/ubsan/TestCases/TypeCheck/Function/function.cpp.) To remove exception specifications from types, the existing internal ASTContext::getFunctionTypeWithExceptionSpec was made public, and some places otherwise unrelated to this change have been adapted to call it, too. This is the cfe part of a patch covering both cfe and compiler-rt. Differential Revision: https://reviews.llvm.org/D40720 llvm-svn: 321859
OpenPOWER on IntegriCloud