summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Clang change: Do not inline hot callsites for samplepgo in thinlto compile ↵Dehao Chen2017-03-211-1/+6
| | | | | | | | | | | | | | | | | | phase. Summary: Because SamplePGO passes will be invoked twice in ThinLTO build: once at compile phase, the other at backend. We want to make sure the IR at the 2nd phase matches the hot part in pro file, thus we do not want to inline hot callsites in the first phase. Reviewers: tejohnson, eraman Reviewed By: tejohnson Subscribers: mehdi_amini, cfe-commits, Prazek Differential Revision: https://reviews.llvm.org/D31202 llvm-svn: 298429
* Update Clang for LLVM rename AttributeSet -> AttributeListReid Kleckner2017-03-2117-197/+180
| | | | llvm-svn: 298394
* IRGen: Do not set dllexport on declarations.Peter Collingbourne2017-03-211-1/+0
| | | | | | | | | | | Setting dllexport on a declaration has no effect, as we do not emit export directives for declarations. Part of the fix for PR32334. Differential Revision: https://reviews.llvm.org/D31162 llvm-svn: 298330
* Add a function to MD5 a file's contents.Zachary Turner2017-03-201-1/+1
| | | | | | | | | | | | | | | In doing so, clean up the MD5 interface a little. Most existing users only care about the lower 8 bytes of an MD5, but for some users that care about the upper and lower, there wasn't a good interface. Furthermore, consumers of the MD5 checksum were required to handle endianness details on their own, so it seems reasonable to abstract this into a nicer interface that just gives you the right value. Differential Revision: https://reviews.llvm.org/D31105 llvm-svn: 298322
* [X86] Add NumRegisterParameters Module Flag.Nirav Dave2017-03-181-0/+7
| | | | | | | | | | Reviewers: rnk, mkuper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D27051 llvm-svn: 298177
* Remove setting LessPreciseFPMADOption on the TargetOption as it'sEric Christopher2017-03-171-1/+0
| | | | | | unused anywhere in llvm. llvm-svn: 298022
* Use arg_begin() instead of getArgumentList().begin(), the argument list is ↵Reid Kleckner2017-03-161-3/+1
| | | | | | an implementation detail llvm-svn: 297975
* Fix Wdocumentation warningSimon Pilgrim2017-03-141-1/+1
| | | | llvm-svn: 297784
* [ubsan] Use the nicer nullability diagnostic handlersVedant Kumar2017-03-143-9/+15
| | | | | | | | | | | This is a follow-up to r297700 (Add a nullability sanitizer). It addresses some FIXME's re: using nullability-specific diagnostic handlers from compiler-rt, now that the necessary handlers exist. check-ubsan test updates to follow. llvm-svn: 297750
* [CodeGen][ObjC] Fix a bug where the type of an ivar wasn't encodedAkira Hatanaka2017-03-141-1/+1
| | | | | | | | | | correctly. This fixes PR30413. Patch by David Lobron. llvm-svn: 297702
* [ubsan] Add a nullability sanitizerVedant Kumar2017-03-145-22/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach UBSan to detect when a value with the _Nonnull type annotation assumes a null value. Call expressions, initializers, assignments, and return statements are all checked. Because _Nonnull does not affect IRGen, the new checks are disabled by default. The new driver flags are: -fsanitize=nullability-arg (_Nonnull violation in call) -fsanitize=nullability-assign (_Nonnull violation in assignment) -fsanitize=nullability-return (_Nonnull violation in return stmt) -fsanitize=nullability (all of the above) This patch builds on top of UBSan's existing support for detecting violations of the nonnull attributes ('nonnull' and 'returns_nonnull'), and relies on the compiler-rt support for those checks. Eventually we will need to update the diagnostic messages in compiler-rt (there are FIXME's for this, which will be addressed in a follow-up). One point of note is that the nullability-return check is only allowed to kick in if all arguments to the function satisfy their nullability preconditions. This makes it necessary to emit some null checks in the function body itself. Testing: check-clang and check-ubsan. I also built some Apple ObjC frameworks with an asserts-enabled compiler, and verified that we get valid reports. Differential Revision: https://reviews.llvm.org/D30762 llvm-svn: 297700
* Fix -Wunused-lambda-capture warning in new codeReid Kleckner2017-03-131-1/+1
| | | | llvm-svn: 297681
* Modules: Use hash of PCM content for SIGNATUREDuncan P. N. Exon Smith2017-03-132-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Change ASTFileSignature from a random 32-bit number to the hash of the PCM content. - Move definition ASTFileSignature to Basic/Module.h so Module and ASTSourceDescriptor can use it. - Change the signature from uint64_t to std::array<uint32_t,5>. - Stop using (saving/reading) the size and modification time of PCM files when there is a valid SIGNATURE. - Add UNHASHED_CONTROL_BLOCK, and use it to store the SIGNATURE record and other records that shouldn't affect the hash. Because implicit modules reuses the same file for multiple levels of -Werror, this includes DIAGNOSTIC_OPTIONS and DIAG_PRAGMA_MAPPINGS. This helps to solve a PCH + implicit Modules dependency issue: PCH files are handled by the external build system, whereas implicit modules are handled by internal compiler build system. This prevents invalidating a PCH when the compiler overwrites a PCM file with the same content (modulo the diagnostic differences). Design and original patch by Manman Ren! llvm-svn: 297655
* [Linker] Provide callback for internalizationJonas Devlieghere2017-03-131-7/+24
| | | | | | Differential Revision: https://reviews.llvm.org/D30738 llvm-svn: 297649
* [x86] these aren't the undefs you're looking for (PR32176)Sanjay Patel2017-03-121-1/+6
| | | | | | | | | | | | | x86 has undef SSE/AVX intrinsics that should represent a bogus register operand. This is not the same as LLVM's undef value which can take on multiple bit patterns. There are better solutions / follow-ups to this discussed here: https://bugs.llvm.org/show_bug.cgi?id=32176 ...but this should prevent miscompiles with a one-line code change. Differential Revision: https://reviews.llvm.org/D30834 llvm-svn: 297588
* [AMDGPU] Add builtin functions readlane ds_permute mov_dppYaxun Liu2017-03-101-0/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D30551 llvm-svn: 297436
* [DebugInfo] Append extended dereferencing mechanism to variables' ↵Konstantin Zhuravlyov2017-03-092-2/+35
| | | | | | | | DIExpression for targets that support more than one address space Differential Revision: https://reviews.llvm.org/D29673 llvm-svn: 297397
* Retry: [ubsan] Detect UB loads from bitfieldsVedant Kumar2017-03-093-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | It's possible to load out-of-range values from bitfields backed by a boolean or an enum. Check for UB loads from bitfields. This is the motivating example: struct S { BOOL b : 1; // Signed ObjC BOOL. }; S s; s.b = 1; // This is actually stored as -1. if (s.b == 1) // Evaluates to false, -1 != 1. ... Changes since the original commit: - Single-bit bools are a special case (see CGF::EmitFromMemory), and we can't avoid dealing with them when loading from a bitfield. Don't try to insert a check in this case. Differential Revision: https://reviews.llvm.org/D30423 llvm-svn: 297389
* Revert "[ubsan] Detect UB loads from bitfields"Vedant Kumar2017-03-093-6/+5
| | | | | | | | This reverts commit r297298. It breaks the self-host on this bot: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/962/steps/build%20clang%2Fubsan/logs/stdio llvm-svn: 297331
* [DebugInfo] Add address space when creating DIDerivedTypesKonstantin Zhuravlyov2017-03-081-6/+17
| | | | | | Differential Revision: https://reviews.llvm.org/D29671 llvm-svn: 297321
* [ubsan] Detect UB loads from bitfieldsVedant Kumar2017-03-083-5/+6
| | | | | | | | | | | | | | | | | | | | It's possible to load out-of-range values from bitfields backed by a boolean or an enum. Check for UB loads from bitfields. This is the motivating example: struct S { BOOL b : 1; // Signed ObjC BOOL. }; S s; s.b = 1; // This is actually stored as -1. if (s.b == 1) // Evaluates to false, -1 != 1. ... Differential Revision: https://reviews.llvm.org/D30423 llvm-svn: 297298
* Honor __unaligned in codegen for declarations and expressionsRoger Ferrer Ibanez2017-03-081-0/+2
| | | | | | | | | | | This patch honors the unaligned type qualifier (currently available through he keyword __unaligned and -fms-extensions) in CodeGen. In the current form the patch affects declarations and expressions. It does not affect fields of classes. Differential Revision: https://reviews.llvm.org/D30166 llvm-svn: 297276
* [AST/ObjC] Make ObjCCategoryImplDecl consistent with ObjCCategoryDecl and ↵Argyrios Kyrtzidis2017-03-071-2/+2
| | | | | | | | use the category name as its DeclName This also addresses the badness in ObjCCategoryImplDecl's API, which was hiding NamedDecl's APIs with different meaning. llvm-svn: 297131
* Don't assume cleanup emission preserves dominance in expr evaluationReid Kleckner2017-03-065-25/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full expression may cause the new insertion point to not be dominated by the result of the inner expression. Consider this example: struct Foo { Foo(); ~Foo(); int x; }; int g(Foo, int); int f(bool cond) { int n = g(Foo(), ({ if (cond) return 0; 42; })); return n; } Before this change, result of the call to 'g' did not dominate its use in the store to 'n'. The early return exit from the statement expression branches to a shared cleanup block, which ends in a switch between the fallthrough destination (the assignment to 'n') or the function exit block. This change solves the problem by spilling and reloading expression evaluation results when any of the active cleanups have branches. I audited the other call sites of enterFullExpression, and they don't appear to keep and Values live across the site of the cleanup, except in ARC code. I wasn't able to create a test case for ARC that exhibits this problem, though. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30590 llvm-svn: 297084
* [coroutines] Add co_return statement emissionGor Nishanov2017-03-063-2/+37
| | | | | | | | | | | | | | | | | Summary: Added co_return statement emission. Tweaked coro-alloc.cpp test to use co_return to trigger coroutine processing instead of co_await, since this change starts emitting the body of the coroutine and await expression handling has not been upstreamed yet. Reviewers: rsmith, majnemer, EricWF, aaron.ballman Reviewed By: rsmith Subscribers: majnemer, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D29979 llvm-svn: 297076
* [MS] Add support for __ud2 and __int2c MSVC intrinsicsReid Kleckner2017-03-061-0/+15
| | | | | | This was requested in PR31958 and elsewhere. llvm-svn: 297057
* Further fixes and improvements to the ConstantInitBuilder API.John McCall2017-03-061-6/+95
| | | | llvm-svn: 297050
* [CodeGen][Blocks] Refactor capture handling in code that generatesAlex Lorenz2017-03-061-118/+173
| | | | | | | | | | | | | block copy/destroy routines This is a preparation commit for work on merging unique block copy/destroy helper functions. rdar://22950898 Differential Revision: https://reviews.llvm.org/D30345 llvm-svn: 297023
* [XRay] [clang] Allow logging the first argument of a function call.Dean Michael Berris2017-03-061-0/+4
| | | | | | | | | | | | | | | | Summary: Functions with the "xray_log_args" attribute will tell LLVM to emit a special XRay sled for compiler-rt to copy any call arguments to your logging handler. Reviewers: dberris Reviewed By: dberris Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D29704 llvm-svn: 296999
* [ubsan] Extend the nonnull arg check to ObjCVedant Kumar2017-03-064-15/+39
| | | | | | | | | | UBSan's nonnull argument check applies when a parameter has the "nonnull" attribute. The check currently works for FunctionDecls, but not for ObjCMethodDecls. This patch extends the check to work for ObjC. Differential Revision: https://reviews.llvm.org/D30599 llvm-svn: 296996
* Refactor ConstantInitBuilder to allow other frontends to moreJohn McCall2017-03-041-19/+79
| | | | | | | | | | easily extend the aggregate-builder API. Stupid missing language features. Also add APIs for constructing a relative reference and computing the offset of a position from the start of the initializer. llvm-svn: 296979
* Promote ConstantInitBuilder to be a public CodeGen API; it'sJohn McCall2017-03-0212-453/+141
| | | | | | a generally useful utility for other frontends. NFC. llvm-svn: 296806
* PR32042: Create inlined debug info for EmitInlinedInheritingCXXConstructorCall.Adrian Prantl2017-02-273-27/+139
| | | | | | | | | | | | | | | | | | When clang emits an inheriting C++ constructor it may inline code during the CodeGen phase. This patch ensures that any debug info in this inlined code gets a proper inlined location. Otherwise we can end up with invalid debug info metadata, since all inlined local variables and function arguments would be reparented into the call site. Analogous to ApplyInlineLocation this patch introduces a ApplyInlineDebugLocation scoped helper to facilitate entering an inlined scope and cleaning up afterwards. This fixes one of the issues discovered in PR32042. rdar://problem/30679307 llvm-svn: 296388
* [ubsan] Factor out logic to emit a range check. NFC.Vedant Kumar2017-02-272-29/+50
| | | | | | | This is a readability improvement, but it will also help prep an upcoming patch to detect UB loads from bitfields. llvm-svn: 296374
* C++ DR1611, 1658, 2180: implement "potentially constructed subobject" rules ↵Richard Smith2017-02-251-0/+14
| | | | | | | | | | | | | | | | | | | | | | for special member functions. Essentially, as a base class constructor does not construct virtual bases, such a constructor for an abstract class does not need the corresponding base class construction to be valid, and likewise for destructors. This creates an awkward situation: clang will sometimes generate references to the complete object and deleting destructors for an abstract class (it puts them in the construction vtable for a derived class). But we can't generate a "correct" version of these because we can't generate references to base class constructors any more (if they're template specializations, say, we might not have instantiated them and can't assume any other TU will emit a copy). Fortunately, we don't need to, since no correct program can ever invoke them, so instead emit symbols that just trap. We should stop emitting references to these symbols, but still need to emit definitions for compatibility. llvm-svn: 296275
* Fix -Wparentheses warningVedant Kumar2017-02-251-2/+2
| | | | llvm-svn: 296246
* Retry: [profiling] Fix profile counter increment when emitting selects (PR32019)Vedant Kumar2017-02-254-12/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | 2nd attempt: the first was in r296231, but it had a use after lifetime bug. Clang has logic to lower certain conditional expressions directly into llvm select instructions. However, it does not emit the correct profile counter increment as it does this: it emits an unconditional increment of the counter for the 'then branch', even if the value selected is from the 'else branch' (this is PR32019). That means, given the following snippet, we would report that "0" is selected twice, and that "1" is never selected: int f1(int x) { return x ? 0 : 1; ^2 ^0 } f1(0); f1(1); Fix the problem by using the instrprof_increment_step intrinsic to do the proper increment. llvm-svn: 296245
* Revert "[profiling] Fix profile counter increment when emitting selects ↵Vedant Kumar2017-02-254-23/+12
| | | | | | | | | | | | | | | | | | | | | (PR32019)" This reverts commit r296231. It causes an assertion failure on 32-bit machines clang: /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/lib/IR/Instructions.cpp:263: void llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, const llvm::Twine&): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"' failed. llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5fbfa) llvm::sys::RunSignalHandlers() (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5dc7e) SignalHandler(int) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5dde2) __restore_rt (/lib64/libpthread.so.0+0x3f1d00efa0) __GI_raise /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 __GI_abort /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/stdlib/abort.c:92:0 __assert_fail_base /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/assert/assert.c:92:0 (/lib64/libc.so.6+0x3f1c82e622) llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, llvm::Twine const&) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1804e3a) clang::CodeGen::CodeGenPGO::emitCounterIncrement(clang::CodeGen::CGBuilderTy&, clang::Stmt const*, llvm::Value*) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1ec7891) llvm-svn: 296234
* [profiling] Fix profile counter increment when emitting selects (PR32019)Vedant Kumar2017-02-254-12/+23
| | | | | | | | | | | | | | | | | | | | | | | | Clang has logic to lower certain conditional expressions directly into llvm select instructions. However, it does not emit the correct profile counter increment as it does this: it emits an unconditional increment of the counter for the 'then branch', even if the value selected is from the 'else branch' (this is PR32019). That means, given the following snippet, we would report that "0" is selected twice, and that "1" is never selected: int f1(int x) { return x ? 0 : 1; ^2 ^0 } f1(0); f1(1); Fix the problem by using the instrprof_increment_step intrinsic to do the proper increment. llvm-svn: 296231
* [ubsan] Detect signed overflow UB in remainder operationsVedant Kumar2017-02-251-4/+4
| | | | | | | | | Teach ubsan to diagnose remainder operations which have undefined behavior due to signed overflow (e.g INT_MIN % -1). Differential Revision: https://reviews.llvm.org/D29437 llvm-svn: 296214
* [ubsan] Omit superflous overflow checks for promoted arithmetic (PR20193)Vedant Kumar2017-02-251-4/+71
| | | | | | | | | | | | | | | | C requires the operands of arithmetic expressions to be promoted if their types are smaller than an int. Ubsan emits overflow checks when this sort of type promotion occurs, even if there is no way to actually get an overflow with the promoted type. This patch teaches clang how to omit the superflous overflow checks (addressing PR20193). Testing: check-clang and check-ubsan. Differential Revision: https://reviews.llvm.org/D29369 llvm-svn: 296213
* Represent pass_object_size attrs in ExtParameterInfoGeorge Burgess IV2017-02-241-39/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The goal of this is to fix a bug in modules where we'd merge FunctionDecls that differed in their pass_object_size attributes. Since we can overload on the presence of pass_object_size attributes, this behavior is incorrect. We don't represent `N` in `pass_object_size(N)` as part of ExtParameterInfo, since it's an error to overload solely on the value of N. This means that we have a bug if we have two modules that declare functions that differ only in their pass_object_size attrs, like so: // In module A, from a.h void foo(char *__attribute__((pass_object_size(0)))); // In module B, from b.h void foo(char *__attribute__((pass_object_size(1)))); // In module C, in main.c #include "a.h" #include "b.h" At the moment, we'll merge the foo decls, when we should instead emit a diagnostic about an invalid overload. We seem to have similar (silent) behavior if we overload only on the return type of `foo` instead; I'll try to find a good place to put a FIXME (or I'll just file a bug) soon. This patch also fixes a bug where we'd not output the proper extended parameter info for declarations with pass_object_size attrs. llvm-svn: 296076
* [profiling] PR31992: Don't skip interesting non-base constructorsVedant Kumar2017-02-243-5/+12
| | | | | | | | | Fix the fact that we don't assign profile counters to constructors in classes with virtual bases, or constructors with variadic parameters. Differential Revision: https://reviews.llvm.org/D30131 llvm-svn: 296062
* NFC, Remove commented out block of code from CGBlocks.cppAlex Lorenz2017-02-241-18/+0
| | | | | | | This is a preparation clean-up commit around the code that emits block copy/dispose routines. llvm-svn: 296054
* [CodeGen] Silence unused variable warning in Release builds.Benjamin Kramer2017-02-231-0/+2
| | | | llvm-svn: 296034
* [CodeGen] Fix ExtParameterInfo bugs in C++ CodeGen code.George Burgess IV2017-02-236-22/+62
| | | | | | | | | | | | | | | | This patch makes use of the prefix/suffix ABI argument distinction that was introduced in r295870, so that we now emit ExtParameterInfo at the correct offset for member calls that have added ABI arguments. I don't see a good way to test the generated param info, since we don't actually seem to use it in CGFunctionInfo outside of Swift. Any suggestions/thoughts for how to better test this are welcome. :) This patch also fixes a small bug with inheriting constructors: if we decide not to pass args into an base class ctor, we would still generate ExtParameterInfo as though we did. The added test-case is for that behavior. llvm-svn: 296024
* [ObjC][CodeGen] CodeGen support for @available.Erik Pilkington2017-02-234-0/+40
| | | | | | | | | | | | CodeGens uses of @available into calls to the compiler-rt function __isOSVersionAtLeast. This commit is part of a feature that I proposed here: http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html Differential revision: https://reviews.llvm.org/D27827 llvm-svn: 296015
* [CodeGen] Don't reemit expressions for pass_object_size params.George Burgess IV2017-02-233-24/+51
| | | | | | | | | | | | | | This fixes an assertion failure in cases where we had expression statements that declared variables nested inside of pass_object_size args. Since we were emitting the same ExprStmt twice (once for the arg, once for the @llvm.objectsize call), we were getting issues with redefining locals. This also means that we can be more lax about when we emit @llvm.objectsize for pass_object_size args: since we're reusing the arg's value itself, we don't have to care so much about side-effects. llvm-svn: 295935
* Rename a helper function, NFC.Vedant Kumar2017-02-233-6/+7
| | | | llvm-svn: 295918
* [CodeGen] Add param info for ctors with ABI args.George Burgess IV2017-02-221-1/+11
| | | | | | This fixes a few assertion failures. Please see the added test case. llvm-svn: 295894
OpenPOWER on IntegriCloud