summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Use FPContractModeKind universallyAdam Nemet2017-03-292-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FPContractModeKind is the codegen option flag which is already ternary (off, on, fast). This makes it universally the type for the contractable info across the front-end: * In FPOptions (i.e. in the Sema + in the expression nodes). * In LangOpts::DefaultFPContractMode which is the option that initializes FPOptions in the Sema. Another way to look at this change is that before fp-contractable on/off were the only states handled to the front-end: * For "on", FMA folding was performed by the front-end * For "fast", we simply forwarded the flag to TargetOptions to handle it in LLVM Now off/on/fast are all exposed because for fast we will generate fast-math-flags during CodeGen. This is toward moving fp-contraction=fast from an LLVM TargetOption to a FastMathFlag in order to fix PR25721. --- This is a recommit of r299027 with an adjustment to the test CodeGenCUDA/fp-contract.cu. The test assumed that even though -ffp-contract=on is passed FE-based folding of FMA won't happen. This is obviously wrong since the user is asking for this explicitly with the option. CUDA is different that -ffp-contract=fast is on by default. The test used to "work" because contract=fast and contract=on were maintained separately and we didn't fold in the FE because contract=fast was on due to the target-default. This patch consolidates the contract=on/fast/off state into a ternary state hence the change in behavior. --- Differential Revision: https://reviews.llvm.org/D31167 llvm-svn: 299033
* Revert "Use FPContractModeKind universally"Adam Nemet2017-03-292-5/+10
| | | | | | | | This reverts commit r299027. It's causing a test failure in clang's CodeGenCUDE/fp-contract.cu llvm-svn: 299029
* Use FPContractModeKind universallyAdam Nemet2017-03-292-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | FPContractModeKind is the codegen option flag which is already ternary (off, on, fast). This makes it universally the type for the contractable info across the front-end: * In FPOptions (i.e. in the Sema + in the expression nodes). * In LangOpts::DefaultFPContractMode which is the option that initializes FPOptions in the Sema. Another way to look at this change is that before fp-contractable on/off were the only states handled to the front-end: * For "on", FMA folding was performed by the front-end * For "fast", we simply forwarded the flag to TargetOptions to handle it in LLVM Now off/on/fast are all exposed because for fast we will generate fast-math-flags during CodeGen. This is toward moving fp-contraction=fast from an LLVM TargetOption to a FastMathFlag in order to fix PR25721. Differential Revision: https://reviews.llvm.org/D31167 llvm-svn: 299027
* [coroutines] Handle get_return_object_on_allocation_failureGor Nishanov2017-03-271-1/+18
| | | | | | | | | | | | | | | | | Summary: If promise_type has get_return_object_on_allocation_failure defined, check if an allocation function returns nullptr, and if so, return the result of get_return_object_on_allocation_failure(). Reviewers: rsmith, EricWF Reviewed By: EricWF Subscribers: mehdi_amini, cfe-commits Differential Revision: https://reviews.llvm.org/D31399 llvm-svn: 298891
* Encapsulate FPOptions and use it consistentlyAdam Nemet2017-03-273-10/+9
| | | | | | | | | | | | | | | | | | Sema holds the current FPOptions which is adjusted by 'pragma STDC FP_CONTRACT'. This then gets propagated into expression nodes as they are built. This encapsulates FPOptions so that this propagation happens opaquely rather than directly with the fp_contractable on/off bit. This allows controlled transitioning of fp_contractable to a ternary value (off, on, fast). It will also allow adding more fast-math flags later. This is toward moving fp-contraction=fast from an LLVM TargetOption to a FastMathFlag in order to fix PR25721. Differential Revision: https://reviews.llvm.org/D31166 llvm-svn: 298877
* [coroutines] Add codegen for await and yield expressionsGor Nishanov2017-03-265-9/+190
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Details: Emit suspend expression which roughly looks like: auto && x = CommonExpr(); if (!x.await_ready()) { llvm_coro_save(); x.await_suspend(...); (*) llvm_coro_suspend(); (**) } x.await_resume(); where the result of the entire expression is the result of x.await_resume() (*) If x.await_suspend return type is bool, it allows to veto a suspend: if (x.await_suspend(...)) llvm_coro_suspend(); (**) llvm_coro_suspend() encodes three possible continuations as a switch instruction: %where-to = call i8 @llvm.coro.suspend(...) switch i8 %where-to, label %coro.ret [ ; jump to epilogue to suspend i8 0, label %yield.ready ; go here when resumed i8 1, label %yield.cleanup ; go here when destroyed ] llvm-svn: 298784
* Revert r298491 and r298494 which changed Clang's handling of 'nonnull'Chandler Carruth2017-03-241-56/+34
| | | | | | | | | | | | | | | | | attributes. These patches don't work because we can't currently access the parameter information in a reliable way when building attributes. I thought this would be relatively straightforward to fix, but it seems not to be the case. Fixing this will requrie a substantial re-plumbing of machinery to allow attributes to be handled in this location, and several other fixes to the attribute machinery should probably be made at the same time. All of this will make the patch .... substantially more complicated. Reverting for now as there are active miscompiles caused by the current version. llvm-svn: 298695
* Remove all uses of std::mem_fun and std::bind1st removed in C++17.Richard Smith2017-03-231-1/+1
| | | | llvm-svn: 298657
* [ThinLTO] Clang support for emitting minimized bitcode for thin linkTeresa Johnson2017-03-231-2/+17
| | | | | | | | | | | | | | | | | Summary: Clang companion patch to LLVM patch D31027, which adds support for emitting minimized bitcode file for use in the thin link step. Add a cc1 option -fthin-link-bitcode=<file> to trigger this behavior. Depends on D31027. Reviewers: mehdi_amini, pcc Subscribers: cfe-commits, Prazek Differential Revision: https://reviews.llvm.org/D31050 llvm-svn: 298639
* [CodeGen] Emit a CoreFoundation link guard when @available is usedAlex Lorenz2017-03-233-0/+38
| | | | | | | | | | | | | | | | After r297760, __isOSVersionAtLeast in compiler-rt loads the CoreFoundation symbols at runtime. This means that `@available` will always fail when used in a binary without a linked CoreFoundation. This commit forces Clang to emit a reference to a CoreFoundation symbol when `@available` is used to ensure that linking will fail when CoreFoundation isn't linked with the build product. rdar://31039592 Differential Revision: https://reviews.llvm.org/D30977 llvm-svn: 298588
* [X86] Implement __readgsqword (and the rest) as builtins (PR32373)Hans Wennborg2017-03-221-10/+24
| | | | | | | | | | | | | | It seems MS headers have started using __readgsqword, and since it's used in a header that doesn't include intrin.h, we can't implement it as an inline function anymore. That was already the case for __readfsdword, which Saleem added support for in r220859. This patch reuses that codegen to implement all of __read[fg]s{byte,word,dword,qword}. Differential Revision: https://reviews.llvm.org/D31248 llvm-svn: 298538
* Remove an overly aggressive assert in r298491 and leave a commentChandler Carruth2017-03-221-1/+5
| | | | | | | | | | explaining why we have to ignore errors here even though in other parts of codegen we can be more strict with builtins. Also add a test case based on the code in a TSan test that found this issue. llvm-svn: 298494
* [nonnull] Teach Clang to attach the nonnull LLVM attribute toChandler Carruth2017-03-221-34/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | declarations and calls instead of just definitions, and then teach it to *not* attach such attributes even if the source code contains them. This follows the design direction discussed on cfe-dev here: http://lists.llvm.org/pipermail/cfe-dev/2017-January/052066.html The idea is that for C standard library builtins, even if the library vendor chooses to annotate their routines with __attribute__((nonnull)), we will ignore those attributes which pertain to pointer arguments that have an associated size. This allows the widespread (and seemingly reasonable) pattern of calling these routines with a null pointer and a zero size. I have only done this for the library builtins currently recognized by Clang, but we can now trivially add to this set. This will be controllable with -fno-builtin if anyone should care to do so. Note that this does *not* change the AST. As a consequence, warnings, static analysis, and source code rewriting are not impacted. This isn't even a regression on any platform as neither Clang nor LLVM have ever put 'nonnull' onto these arguments for declarations. All this patch does is enable it on other declarations while preventing us from ever accidentally enabling it on these libc functions due to a library vendor. It will also allow any other libraries using this annotation to gain optimizations based on the annotation even when only a declaration is visible. llvm-svn: 298491
* Apply clang-tidy's performance-unnecessary-value-param to parts of clang.Benjamin Kramer2017-03-211-1/+1
| | | | | | No functionality change intended. llvm-svn: 298443
* Let llvm.objectsize be conservative with null pointersGeorge Burgess IV2017-03-212-6/+10
| | | | | | | D28494 adds another parameter to @llvm.objectsize. Clang needs to be sure to pass that third arg whenever applicable. llvm-svn: 298431
* 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
OpenPOWER on IntegriCloud