aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CGCall.cpp
AgeCommit message (Collapse)AuthorFilesLines
2022-02-04Don't assume that a new cleanup was added to InnermostEHScope.James Y Knight1-1/+1
After fa87fa97fb79, this was no longer guaranteed to be the cleanup just added by this code, if IsEHCleanup got disabled. Instead, use stable_begin(), which _is_ guaranteed to be the cleanup just added. This caused a crash when a object that is callee destroyed (e.g. with the MS ABI) was passed in a call from a noexcept function. Added a test to verify. Fixes: fa87fa97fb79
2022-01-25[NFC] Remove uses of PointerType::getElementType()Nikita Popov1-9/+7
Instead use either Type::getPointerElementType() or Type::getNonOpaquePointerElementType(). This is part of D117885, in preparation for deprecating the API.
2022-01-20[IRGen] Do not overwrite existing attributes in CGCall.Florian Hahn1-2/+2
When adding new attributes, existing attributes are dropped. While this appears to be a longstanding issue, this was highlighted by D105169 which dropped a lot of attributes due to adding the new noundef attribute. Ahmed Bougacha (@ab) tracked down the issue and provided the fix in CGCall.cpp. I bundled it up and updated the tests.
2022-01-16[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and ↵hyeongyu kim1-2/+2
turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169
2022-01-12[NFC] Minimize noundef analysis when disabledKevin Athey1-2/+3
Minor adjustment in order of noundef analysis to be a bit more optimal (when disabled). Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D117078
2022-01-10Use a sorted array instead of a map to store AttrBuilder string attributesSerge Guelton1-12/+12
Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2021-12-23[CodeGen] Use correct element type for store to sretNikita Popov1-4/+11
sret is special in that it does not use the memory type representation. Manually construct the LValue using ConvertType instead of ConvertTypeForMem here. This fixes matrix-lowering-opt-levels.c on s390x.
2021-12-19[CodeGen] remove creation of FP cast function attributeSanjay Patel1-5/+0
This is the last cleanup step resulting from D115804 . Now that clang uses intrinsics when we're in the special FP mode, we don't need a function attribute as an indicator to the backend. The LLVM part of the change is in D115885. Differential Revision: https://reviews.llvm.org/D115886
2021-12-17[clang] Use llvm::reverse (NFC)Kazu Hirata1-2/+1
2021-12-17[CodeGen] Avoid more pointer element type accessesNikita Popov1-2/+1
2021-12-16[CodeGen] Avoid more pointer element type accessesNikita Popov1-3/+4
This is enough to build sqlite3 with opaque pointers.
2021-12-16[CodeGen] Avoid more pointer element type accessesNikita Popov1-2/+1
2021-12-15[CodeGen] Avoid some pointer element type accessesNikita Popov1-6/+6
2021-12-14[CodeGen] Require use of Address::invalid() for invalid address (NFC)Nikita Popov1-5/+2
This no longer allows creating an invalid Address through the regular constructor. There were only two places that did this (AggValueSlot and EHCleanupScope) which did this by converting a potential nullptr into an Address. I've fixed both of these by directly storing an Address instead. This is intended as a bit of preliminary cleanup for D103465. Differential Revision: https://reviews.llvm.org/D115630
2021-12-06Introduce _BitInt, deprecate _ExtIntAaron Ballman1-1/+1
WG14 adopted the _ExtInt feature from Clang for C23, but renamed the type to be _BitInt. This patch does the vast majority of the work to rename _ExtInt to _BitInt, which accounts for most of its size. The new type is exposed in older C modes and all C++ modes as a conforming extension. However, there are functional changes worth calling out: * Deprecates _ExtInt with a fix-it to help users migrate to _BitInt. * Updates the mangling for the type. * Updates the documentation and adds a release note to warn users what is going on. * Adds new diagnostics for use of _BitInt to call out when it's used as a Clang extension or as a pre-C23 compatibility concern. * Adds new tests for the new diagnostic behaviors. I want to call out the ABI break specifically. We do not believe that this break will cause a significant imposition for early adopters of the feature, and so this is being done as a full break. If it turns out there are critical uses where recompilation is not an option for some reason, we can consider using ABI tags to ease the transition.
2021-11-09[OpenMP] Remove doing assumption propagation in the front end.Joseph Huber1-15/+9
This patch removes the assumption propagation that was added in D110655 primarily to get assumption informatino on opaque call sites for optimizations. The analysis done in D111445 allows us to do this more intelligently in the back-end. Depends on D111445 Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D111463
2021-11-09Revert "[Clang/Test]: Rename enable_noundef_analysis to ↵hyeongyu kim1-2/+2
disable-noundef-analysis and turn it off by default" This reverts commit aacfbb953eb705af2ecfeb95a6262818fa85dd92. Revert "Fix lit test failures in CodeGenCoroutines" This reverts commit 63fff0f5bffe20fa2c84a45a41161afa0043cb34.
2021-11-06[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and ↵hyeongyukim1-2/+2
turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169 [Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and turn it off by default (2) This patch updates test files after D105169. Autogenerated test codes are changed by `utils/update_cc_test_checks.py,` and non-autogenerated test codes are changed as follows: (1) I wrote a python script that (partially) updates the tests using regex: {F18594904} The script is not perfect, but I believe it gives hints about which patterns are updated to have `noundef` attached. (2) The remaining tests are updated manually. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D108453 Resolve lit failures in clang after 8ca4b3e's land Fix lit test failures in clang-ppc* and clang-x64-windows-msvc Fix missing failures in clang-ppc64be* and retry fixing clang-x64-windows-msvc Fix internal_clone(aarch64) inline assembly
2021-11-06Revert "[Clang/Test]: Rename enable_noundef_analysis to ↵Juneyoung Lee1-2/+2
disable-noundef-analysis and turn it off by default" This reverts commit 7584ef766a7219b6ee5a400637206d26e0fa98ac.
2021-11-06[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and ↵Juneyoung Lee1-2/+2
turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169
2021-10-18Revert D105169 due to the two-stage failure in ASANJuneyoung Lee1-2/+2
This reverts the following commits: 37ca7a795b277c20c02a218bf44052278c03344b 9aa6c72b92b6c89cc6d23b693257df9af7de2d15 705387c5074bcca36d626882462ebbc2bcc3bed4 8ca4b3ef19fe82d7ad6a6e1515317dcc01b41515 80dba72a669b5416e97a42fd2c2a7bc5a6d3f44a
2021-10-16[Clang/Test]: Rename enable_noundef_analysis to disable-noundef-analysis and ↵Juneyoung Lee1-2/+2
turn it off by default Turning on `enable_noundef_analysis` flag allows better codegen by removing freeze instructions. I modified clang by renaming `enable_noundef_analysis` flag to `disable-noundef-analysis` and turning it off by default. Test updates are made as a separate patch: D108453 Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105169
2021-10-09[NFC] [Clang] Use global enum for explicit float modeQiu Chaofan1-3/+3
Currently, there're multiple float types that can be represented by __attribute__((mode(xx))). It's parsed, and then a corresponding type is created if available. This refactor moves the enum for mode into a global enum class visible to ASTContext. Reviewed By: aaron.ballman, erichkeane Differential Revision: https://reviews.llvm.org/D111391
2021-10-08[clang] Set max allowed alignment to 2^32Arthur Eubanks1-1/+1
Followup to D110451 which set LLVM's max allowed alignment to 2^32. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D111250
2021-10-08[clang] Option control afn flagMasoud Ataei1-0/+2
Clang option to set/unset afn fast-math flag. Differential: https://reviews.llvm.org/D106191 Reviewd with: aaron.ballman, erichkeane, and others
2021-10-06Reland [IR] Increase max alignment to 4GBArthur Eubanks1-6/+6
Currently the max alignment representable is 1GB, see D108661. Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945. This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits. We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now. The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field. Updating clang's max allowed alignment will come in a future patch. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D110451
2021-10-06Revert "Reland [IR] Increase max alignment to 4GB"Arthur Eubanks1-6/+6
This reverts commit 8d64314ffea55f2ad94c1b489586daa8ce30f451.
2021-10-06Reland [IR] Increase max alignment to 4GBArthur Eubanks1-6/+6
Currently the max alignment representable is 1GB, see D108661. Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945. This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits. We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now. The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field. Updating clang's max allowed alignment will come in a future patch. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D110451
2021-10-06Revert "[IR] Increase max alignment to 4GB"Arthur Eubanks1-6/+6
This reverts commit df84c1fe78130a86445d57563dea742e1b85156a. Breaks some bots
2021-10-06[IR] Increase max alignment to 4GBArthur Eubanks1-6/+6
Currently the max alignment representable is 1GB, see D108661. Setting the align of an object to 4GB is desirable in some cases to make sure the lower 32 bits are clear which can be used for some optimizations, e.g. https://crbug.com/1016945. This uses an extra bit in instructions that carry an alignment. We can store 15 bits of "free" information, and with this change some instructions (e.g. AtomicCmpXchgInst) use 14 bits. We can increase the max alignment representable above 4GB (up to 2^62) since we're only using 33 of the 64 values, but I've just limited it to 4GB for now. The one place we have to update the bitcode format is for the alloca instruction. It stores its alignment into 5 bits of a 32 bit bitfield. I've added another field which is 8 bits and should be future proof for a while. For backward compatibility, we check if the old field has a value and use that, otherwise use the new field. Updating clang's max allowed alignment will come in a future patch. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D110451
2021-09-29[OpenMP] Apply OpenMP assumptions to applicable call sitesJoseph Huber1-19/+32
This patch adds OpenMP assumption attributes to call sites in applicable regions. Currently this applies the caller's assumption attributes to any calls contained within it. So, if a call occurs inside an OpenMP assumes region to a function outside that region, we will assume that call respects the assumptions. This is primarily useful for inline assembly calls used heavily in the OpenMP GPU device runtime, which allows us to then make judgements about what the ASM will do. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D110655
2021-09-10[NFCI][clang] Move allocation alignment manifestation for malloc-like into ↵Roman Lebedev1-18/+0
Sema from Codegen ... so that it happens right next to `AddKnownFunctionAttributesForReplaceableGlobalAllocationFunction()`, which is good for consistency.
2021-08-25[Clang] add support for error+warning fn attrsNick Desaulniers1-0/+9
Add support for the GNU C style __attribute__((error(""))) and __attribute__((warning(""))). These attributes are meant to be put on declarations of functions whom should not be called. They are frequently used to provide compile time diagnostics similar to _Static_assert, but which may rely on non-ICE conditions (ie. relying on compiler optimizations). This is also similar to diagnose_if function attribute, but can diagnose after optimizations have been run. While users may instead simply call undefined functions in such cases to get a linkage failure from the linker, these provide a much more ergonomic and actionable diagnostic to users and do so at compile time rather than at link time. Users instead may be able use inline asm .err directives. These are used throughout the Linux kernel in its implementation of BUILD_BUG and BUILD_BUG_ON macros. These macros generally cannot be converted to use _Static_assert because many of the parameters are not ICEs. The Linux kernel still needs to be modified to make use of these when building with Clang; I have a patch that does so I will send once this feature is landed. To do so, we create a new IR level Function attribute, "dontcall" (both error and warning boil down to one IR Fn Attr). Then, similar to calls to inline asm, we attach a !srcloc Metadata node to call sites of such attributed callees. The backend diagnoses these during instruction selection, while we still know that a call is a call (vs say a JMP that's a tail call) in an arch agnostic manner. The frontend then reconstructs the SourceLocation from that Metadata, and determines whether to emit an error or warning based on the callee's attribute. Link: https://bugs.llvm.org/show_bug.cgi?id=16428 Link: https://github.com/ClangBuiltLinux/linux/issues/1173 Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D106030
2021-08-20[NFC] addAttribute(FunctionIndex) => addFnAttribute()Arthur Eubanks1-3/+1
2021-08-17[NFC] More get/removeAttribute() cleanupArthur Eubanks1-2/+1
2021-08-17[NFC] Cleanup more AttributeList::addAttribute()Arthur Eubanks1-14/+6
2021-08-17[NFC] Migrate some callers away from Function/AttributeLists methods that ↵Arthur Eubanks1-4/+2
take an index These methods can be confusing.
2021-08-13[NFC] Rename AttributeList::hasFnAttribute() -> hasFnAttr()Arthur Eubanks1-1/+1
This is more consistent with similar methods.
2021-08-11CodeGen: No need to check for isExternC if HasStrictReturn is already falseArnold Schwaighofer1-1/+1
NFC intended. Differential Revision: https://reviews.llvm.org/D107841
2021-08-04[clang][AArch64][SVE] Avoid going through memory for fixed/scalable ↵Bradley Smith1-3/+26
predicate casts For fixed SVE types, predicates are represented using vectors of i8, where as for scalable types they are represented using vectors of i1. We can avoid going through memory for casts between these by bitcasting the i1 scalable vectors to/from a scalable i8 vector of matching size, which can then use the existing vector insert/extract logic. Differential Revision: https://reviews.llvm.org/D106860
2021-07-09[Clang] Introduce Swift async calling convention.Varun Gandhi1-4/+5
This change is intended as initial setup. The plan is to add more semantic checks later. I plan to update the documentation as more semantic checks are added (instead of documenting the details up front). Most of the code closely mirrors that for the Swift calling convention. Three places are marked as [FIXME: swiftasynccc]; those will be addressed once the corresponding convention is introduced in LLVM. Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D95561
2021-07-08[CodeGen] Avoid nullptr arg to CreateStructGEP (NFC)Nikita Popov1-1/+2
For now just make the getPointerElementType() explicit.
2021-07-08[CodeGen] Avoid CreateGEP with nullptr type (NFC)Nikita Popov1-2/+2
In preparation for dropping support for it. I've replaced it with a proper type where the correct type was obvious and left an explicit getPointerElementType() where it wasn't.
2021-06-28Fix `-Wunused-variable` warning. NFC.Michael Liao1-1/+1
2021-06-28[UniqueLinkageName] Use exsiting GlobalDecl object instead of reconstructing ↵Hongtao Yu1-1/+2
one. C++ constructors/destructors need to go through a different constructor to construct a GlobalDecl object in order to retrieve their linkage type. This causes an assert failure in the default constructor of GlobalDecl. I'm chaning it to using the exsiting GlobalDecl object. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D102356
2021-06-07[Clang][CodeGen] Set the size of llvm.lifetime to unknown for scalable types.Hsiangkai Wang1-2/+2
If the memory object is scalable type, we do not know the exact size of it at compile time. Set the size of lifetime marker to unknown if the object is scalable one. Differential Revision: https://reviews.llvm.org/D102822
2021-05-28SwiftAsync: add Clang attribute to apply the LLVM `swiftasync` one.Tim Northover1-0/+4
Expected to be used by Swift runtime developers.
2021-05-17[clang CodeGen] Don't crash on large atomic function parameter.Eli Friedman1-2/+2
I wouldn't recommend writing code like the testcase; a function parameter isn't atomic, so using an atomic type doesn't really make sense. But it's valid, so clang shouldn't crash on it. The code was assuming hasAggregateEvaluationKind(Ty) implies Ty is a RecordType, which isn't true. Just use isRecordType() instead. Differential Revision: https://reviews.llvm.org/D102015
2021-05-13Return "[CGCall] Annotate `this` argument with alignment"Roman Lebedev1-5/+11
The original change was reverted because it was discovered that clang mishandles thunks, and they receive wrong attributes for their this/return types - the ones for the function they will call, not the ones they have. While i have tried to fix this in https://reviews.llvm.org/D100388 that patch has been up and stuck for a month now, with little signs of progress. So while it will be good to solve this for real, for now we can simply avoid introducing the bug, by not annotating this/return for thunks. This reverts commit 6270b3a1eafaba4279e021418c5a2c5a35abc002, relanding 0aa0458f1429372038ca6a4edc7e94c96cd9a753.
2021-05-13[Clang][Codegen] Do not annotate thunk's this/return types with ↵Roman Lebedev1-18/+27
align/deref/nonnull attrs As it was discovered in post-commit feedback for 0aa0458f1429372038ca6a4edc7e94c96cd9a753, we handle thunks incorrectly, and end up annotating their this/return with attributes that are valid for their callees, not for thunks themselves. While it would be good to fix this properly, and keep annotating them on thunks, i've tried doing that in https://reviews.llvm.org/D100388 with little success, and the patch is stuck for a month now. So for now, as a stopgap measure, subj.
generated by cgit v1.1 at 2025-10-01 15:46:25 +0000