aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CodeGenFunction.cpp
AgeCommit message (Collapse)AuthorFilesLines
2020-10-26[Annotation] Allows annotation to carry some additional constant arguments.Tyker1-8/+11
This allows using annotation in a much more contexts than it currently has. especially when annotation with template or constexpr. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D88645
2020-10-25[clang] Enable support for #pragma STDC FENV_ACCESSMelanie Blower1-2/+2
Reviewers: rjmccall, rsmith, sepavloff Differential Revision: https://reviews.llvm.org/D87528
2020-10-18[Sema, CodeGen] Implement [[likely]] and [[unlikely]] in SwitchStmtMark de Wever1-21/+25
This implements the likelihood attribute for the switch statement. Based on the discussion in D85091 and D86559 it only handles the attribute when placed on the case labels or the default labels. It also marks the likelihood attribute as feature complete. There are more QoI patches in the pipeline. Differential Revision: https://reviews.llvm.org/D89210
2020-10-04[CodeGen] Improve likelihood branch weightsMark de Wever1-16/+46
Bruno De Fraine discovered some issues with D85091. The branch weights generated for `logical not` and `ternary conditional` were wrong. The `logical and` and `logical or` differed from the code generated of `__builtin_predict`. Adjusted the generated code for the likelihood to match `__builtin_predict`. The patch is based on Bruno's suggestions. Differential Revision: https://reviews.llvm.org/D88363
2020-09-24[xray] Function coverage groupsIan Levesque1-1/+16
Add the ability to selectively instrument a subset of functions by dividing the functions into N logical groups and then selecting a group to cover. By selecting different groups over time you could cover the entire application incrementally with lower overhead than instrumenting the entire application at once. Differential Revision: https://reviews.llvm.org/D87953
2020-09-12Reland [AssumeBundles] Use operand bundles to encode alignment assumptionsTyker1-5/+31
NOTE: There is a mailing list discussion on this: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137632.html Complemantary to the assumption outliner prototype in D71692, this patch shows how we could simplify the code emitted for an alignemnt assumption. The generated code is smaller, less fragile, and it makes it easier to recognize the additional use as a "assumption use". As mentioned in D71692 and on the mailing list, we could adopt this scheme, and similar schemes for other patterns, without adopting the assumption outlining.
2020-09-09Implements [[likely]] and [[unlikely]] in IfStmt.Mark de Wever1-19/+23
This is the initial part of the implementation of the C++20 likelihood attributes. It handles the attributes in an if statement. Differential Revision: https://reviews.llvm.org/D85091
2020-07-28PR46377: Fix dependence calculation for function types and typedefRichard Smith1-1/+0
types. We previously did not treat a function type as dependent if it had a parameter pack with a non-dependent type -- such a function type depends on the arity of the pack so is dependent even though none of the parameter types is dependent. In order to properly handle this, we now treat pack expansion types as always being dependent types (depending on at least the pack arity), and always canonically being pack expansion types, even in the unusual case when the pattern is not a dependent type. This does mean that we can have canonical types that are pack expansions that contain no unexpanded packs, which is unfortunate but not inaccurate. We also previously did not treat a typedef type as instantiation-dependent if its canonical type was not instantiation-dependent. That's wrong because instantiation-dependence is a property of the type sugar, not of the type; an instantiation-dependent type can have a non-instantiation-dependent canonical type.
2020-07-16Temporarily Revert "[AssumeBundles] Use operand bundles to encode alignment ↵Eric Christopher1-31/+5
assumptions" due to the performance bugs filed in https://bugs.llvm.org/show_bug.cgi?id=46753. An SROA change soon may obviate some of these problems. This reverts commit 8d09f20798ac180b1749276bff364682ce0196ab.
2020-07-14[AssumeBundles] Use operand bundles to encode alignment assumptionsTyker1-5/+31
Summary: NOTE: There is a mailing list discussion on this: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137632.html Complemantary to the assumption outliner prototype in D71692, this patch shows how we could simplify the code emitted for an alignemnt assumption. The generated code is smaller, less fragile, and it makes it easier to recognize the additional use as a "assumption use". As mentioned in D71692 and on the mailing list, we could adopt this scheme, and similar schemes for other patterns, without adopting the assumption outlining. Reviewers: hfinkel, xbolva00, lebedev.ri, nikic, rjmccall, spatel, jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: thopre, yamauchi, kuter, fhahn, merge_guards_bot, hiraditya, bollu, rkruppe, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71739
2020-07-08[OpenMPIRBuilder][Fix] Move llvm::omp::types to OpenMPIRBuilder.sstefan11-2/+2
Summary: D82193 exposed a problem with global type definitions in `OMPConstants.h`. This causes a race when running in thinLTO mode. Types now live inside of OpenMPIRBuilder to prevent this from happening. Reviewers: jdoerfert Subscribers: yaxunl, hiraditya, guansong, dexonsmith, aaron.ballman, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D83176
2020-07-04Revert "[AssumeBundles] Use operand bundles to encode alignment assumptions"Roman Lebedev1-31/+5
Assume bundle can have more than one entry with the same name, but at least AlignmentFromAssumptionsPass::extractAlignmentInfo() uses getOperandBundle("align"), which internally assumes that it isn't the case, and happily crashes otherwise. Minimal reduced reproducer: run `opt -alignment-from-assumptions` on target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" %0 = type { i64, %1*, i8*, i64, %2, i32, %3*, i8* } %1 = type opaque %2 = type { i8, i8, i16 } %3 = type { i32, i32, i32, i32 } ; Function Attrs: nounwind define i32 @f(%0* noalias nocapture readonly %arg, %0* noalias %arg1) local_unnamed_addr #0 { bb: call void @llvm.assume(i1 true) [ "align"(%0* %arg, i64 8), "align"(%0* %arg1, i64 8) ] ret i32 0 } ; Function Attrs: nounwind willreturn declare void @llvm.assume(i1) #1 attributes #0 = { nounwind "reciprocal-estimates"="none" } attributes #1 = { nounwind willreturn } This is what we'd have with -mllvm -enable-knowledge-retention This reverts commit c95ffadb2474a4d8c4f598d94d35a9f31d9606cb.
2020-06-27Reland D81869 "Modify FPFeatures to use delta not absolute settings"Melanie Blower1-15/+17
This reverts commit defd43a5b393bb63a902042adf578081b03b171d. with correction to solve msan report To solve https://bugs.llvm.org/show_bug.cgi?id=46166 where the floating point settings in PCH files aren't compatible, rewrite FPFeatures to use a delta in the settings rather than absolute settings. With this patch, these floating point options can be benign. Reviewers: rjmccall Differential Revision: https://reviews.llvm.org/D81869
2020-06-26Revert "Revert "Revert "Modify FPFeatures to use delta not absolute settings"""Melanie Blower1-17/+15
This reverts commit 9518763d710bfbbf9315fa88972c55898be44a0e. Memory sanitizer fails in CGFPOptionsRAII::CGFPOptionsRAII dtor
2020-06-26Revert "Revert "Modify FPFeatures to use delta not absolute settings""Melanie Blower1-15/+17
This reverts commit b55d723ed61052b77e720dcffecac43abe873186. Reapply Modify FPFeatures to use delta not absolute settings To solve https://bugs.llvm.org/show_bug.cgi?id=46166 where the floating point settings in PCH files aren't compatible, rewrite FPFeatures to use a delta in the settings rather than absolute settings. With this patch, these floating point options can be benign. Reviewers: rjmccall Differential Revision: https://reviews.llvm.org/D81869
2020-06-26Revert "Modify FPFeatures to use delta not absolute settings"Melanie Blower1-17/+15
This reverts commit 3a748cbf86cea3844fada04eeff4cc64b01f67e0. I'm reverting this commit because I forgot to format the commit message propertly. Sorry for the thrash.
2020-06-26Modify FPFeatures to use delta not absolute settingsMelanie Blower1-15/+17
2020-06-25[AssumeBundles] Use operand bundles to encode alignment assumptionsTyker1-5/+31
Summary: NOTE: There is a mailing list discussion on this: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137632.html Complemantary to the assumption outliner prototype in D71692, this patch shows how we could simplify the code emitted for an alignemnt assumption. The generated code is smaller, less fragile, and it makes it easier to recognize the additional use as a "assumption use". As mentioned in D71692 and on the mailing list, we could adopt this scheme, and similar schemes for other patterns, without adopting the assumption outlining. Reviewers: hfinkel, xbolva00, lebedev.ri, nikic, rjmccall, spatel, jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: yamauchi, kuter, fhahn, merge_guards_bot, hiraditya, bollu, rkruppe, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71739
2020-06-11[CodeGen] Simplify the way lifetime of block captures is extendedAkira Hatanaka1-6/+0
Rather than pushing inactive cleanups for the block captures at the entry of a full expression and activating them during the creation of the block literal, just call pushLifetimeExtendedDestroy to ensure the cleanups are popped at the end of the scope enclosing the block expression. rdar://problem/63996471 Differential Revision: https://reviews.llvm.org/D81624
2020-06-11Set the LLVM FP optimization flags conservatively.John McCall1-4/+50
Functions can have local pragmas that override the global settings. We set the flags eagerly based on global settings, but if we emit an expression under the influence of a pragma, we clear the appropriate flags from the function. In order to avoid doing a ton of redundant work whenever we emit an FP expression, configure the IRBuilder to default to global settings, and only reconfigure it when we see an FP expression that's not using the global settings. Patch by Michele Scandale! https://reviews.llvm.org/D80462
2020-06-02[SampleFDO] Add use-sample-profile function attribute.Wei Mi1-0/+3
When sampleFDO is enabled, people may expect they can use -fno-profile-sample-use to opt-out using sample profile for a certain file. That could be either for debugging purpose or for performance tuning purpose. However, when thinlto is enabled, if a function in file A compiled with -fno-profile-sample-use is imported to another file B compiled with -fprofile-sample-use, the inlined copy of the function in file B may still get its profile annotated. The inconsistency may even introduce profile unused warning because if the target is not compiled with explicit debug information flag, the function in file A won't have its debug information enabled (debug information will be enabled implicitly only when -fprofile-sample-use is used). After it is imported into file B which is compiled with -fprofile-sample-use, profile annotation for the outline copy of the function will fail because the function has no debug information, and that will trigger profile unused warning. We add a new attribute use-sample-profile to control whether a function will use its sample profile no matter for its outline or inline copies. That will make the behavior of -fno-profile-sample-use consistent. Differential Revision: https://reviews.llvm.org/D79959
2020-06-01Fix how cc1 command line options are mapped into FP options.John McCall1-20/+13
Canonicalize on storing FP options in LangOptions instead of redundantly in CodeGenOptions. Incorporate -ffast-math directly into the values of those LangOptions rather than considering it separately when building FPOptions. Build IR attributes from those options rather than a mix of sources. We should really simplify the driver/cc1 interaction here and have the driver pass down options that cc1 directly honors. That can happen in a follow-up, though. Patch by Michele Scandale! https://reviews.llvm.org/D80315
2020-05-19[CGCall] Annotate references with "align" attribute.Eli Friedman1-59/+4
If we're going to assume references are dereferenceable, we should also assume they're aligned: otherwise, we can't actually dereference them. See also D80072. Differential Revision: https://reviews.llvm.org/D80166
2020-05-11[Matrix] Add matrix type to Clang.Florian Hahn1-0/+2
This patch adds a matrix type to Clang as described in the draft specification in clang/docs/MatrixSupport.rst. It introduces a new option -fenable-matrix, which can be used to enable the matrix support. The patch adds new MatrixType and DependentSizedMatrixType types along with the plumbing required. Loads of and stores to pointers to matrix values are lowered to memory operations on 1-D IR arrays. After loading, the loaded values are cast to a vector. This ensures matrix values use the alignment of the element type, instead of LLVM's large vector alignment. The operators and builtins described in the draft spec will will be added in follow-up patches. Reviewers: martong, rsmith, Bigcheese, anemet, dexonsmith, rjmccall, aaron.ballman Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D72281
2020-05-04Reapply "Add support for #pragma float_control" with buildbot fixesMelanie Blower1-12/+9
Add support for #pragma float_control Reviewers: rjmccall, erichkeane, sepavloff Differential Revision: https://reviews.llvm.org/D72841 This reverts commit fce82c0ed310174fe48e2402ac731b6340098389.
2020-05-01Revert "Reapply "Add support for #pragma float_control" with improvements to"Melanie Blower1-9/+12
This reverts commit 69aacaf699922ffe0450f567e21208c10c84731f.
2020-05-01Reapply "Add support for #pragma float_control" with improvements toMelanie Blower1-12/+9
test cases Add support for #pragma float_control Reviewers: rjmccall, erichkeane, sepavloff Differential Revision: https://reviews.llvm.org/D72841 This reverts commit 85dc033caccaa6ab919d57f9759290be41240146, and makes corrections to the test cases that failed on buildbots.
2020-05-01Revert "Add support for #pragma float_control"Melanie Blower1-9/+12
This reverts commit 4f1e9a17e9d28bdfd035313c96b3a5d4c91a7733. due to fail on buildbot, sorry for the noise
2020-05-01Add support for #pragma float_controlMelanie Blower1-12/+9
Reviewers: rjmccall, erichkeane, sepavloff Differential Revision: https://reviews.llvm.org/D72841
2020-04-27[IR] Replace all uses of CallBase::getCalledValue() with getCalledOperand().Craig Topper1-1/+1
This method has been commented as deprecated for a while. Remove it and replace all uses with the equivalent getCalledOperand(). I also made a few cleanups in here. For example, to removes use of getElementType on a pointer when we could just use getFunctionType from the call. Differential Revision: https://reviews.llvm.org/D78882
2020-04-17Reland Implement _ExtInt as an extended int type specifier.Erich Keane1-0/+2
I fixed the LLDB issue, so re-applying the patch. This reverts commit a4b88c044980337bb14390be654fe76864aa60ec.
2020-04-17Revert "Implement _ExtInt as an extended int type specifier."Sterling Augustine1-2/+0
This reverts commit 61ba1481e200b5b35baa81ffcff81acb678e8508. I'm reverting this because it breaks the lldb build with incomplete switch coverage warnings. I would fix it forward, but am not familiar enough with lldb to determine the correct fix. lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:3958:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch] switch (qual_type->getTypeClass()) { ^ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4633:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch] switch (qual_type->getTypeClass()) { ^ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4889:11: error: enumeration values 'DependentExtInt' and 'ExtInt' not handled in switch [-Werror,-Wswitch] switch (qual_type->getTypeClass()) {
2020-04-17Implement _ExtInt as an extended int type specifier.Erich Keane1-0/+2
Introduction/Motivation: LLVM-IR supports integers of non-power-of-2 bitwidth, in the iN syntax. Integers of non-power-of-two aren't particularly interesting or useful on most hardware, so much so that no language in Clang has been motivated to expose it before. However, in the case of FPGA hardware normal integer types where the full bitwidth isn't used, is extremely wasteful and has severe performance/space concerns. Because of this, Intel has introduced this functionality in the High Level Synthesis compiler[0] under the name "Arbitrary Precision Integer" (ap_int for short). This has been extremely useful and effective for our users, permitting them to optimize their storage and operation space on an architecture where both can be extremely expensive. We are proposing upstreaming a more palatable version of this to the community, in the form of this proposal and accompanying patch. We are proposing the syntax _ExtInt(N). We intend to propose this to the WG14 committee[1], and the underscore-capital seems like the active direction for a WG14 paper's acceptance. An alternative that Richard Smith suggested on the initial review was __int(N), however we believe that is much less acceptable by WG14. We considered _Int, however _Int is used as an identifier in libstdc++ and there is no good way to fall back to an identifier (since _Int(5) is indistinguishable from an unnamed initializer of a template type named _Int). [0]https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html) [1]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf Differential Revision: https://reviews.llvm.org/D73967
2020-04-09[FPEnv] Use single enum to represent rounding modeSerge Pavlov1-19/+3
Now compiler defines 5 sets of constants to represent rounding mode. These are: 1. `llvm::APFloatBase::roundingMode`. It specifies all 5 rounding modes defined by IEEE-754 and is used in `APFloat` implementation. 2. `clang::LangOptions::FPRoundingModeKind`. It specifies 4 of 5 IEEE-754 rounding modes and a special value for dynamic rounding mode. It is used in clang frontend. 3. `llvm::fp::RoundingMode`. Defines the same values as `clang::LangOptions::FPRoundingModeKind` but in different order. It is used to specify rounding mode in in IR and functions that operate IR. 4. Rounding mode representation used by `FLT_ROUNDS` (C11, 5.2.4.2.2p7). Besides constants for rounding mode it also uses a special value to indicate error. It is convenient to use in intrinsic functions, as it represents platform-independent representation for rounding mode. In this role it is used in some pending patches. 5. Values like `FE_DOWNWARD` and other, which specify rounding mode in library calls `fesetround` and `fegetround`. Often they represent bits of some control register, so they are target-dependent. The same names (not values) and a special name `FE_DYNAMIC` are used in `#pragma STDC FENV_ROUND`. The first 4 sets of constants are target independent and could have the same numerical representation. It would simplify conversion between the representations. Also now `clang::LangOptions::FPRoundingModeKind` and `llvm::fp::RoundingMode` do not contain the value for IEEE-754 rounding direction `roundTiesToAway`, although it is supported natively on some targets. This change defines all the rounding mode type via one `llvm::RoundingMode`, which also contains rounding mode for IEEE rounding direction `roundTiesToAway`. Differential Revision: https://reviews.llvm.org/D77379
2020-04-08Make target features check work with ctor and dtor-Erich Keane1-2/+1
The problem was reported in PR45468, applying target features to an always_inline constructor/destructor runs afoul of GlobalDecl construction assert when checking for target-feature compatibility. The core problem is fixed by using the version of the check that takes a FunctionDecl rather than the GlobalDecl. However, while writing the test, I discovered that source locations weren't properly set for this check on ctors/dtors. This patch also fixes constructors and CALLED destructors. Unfortunately, it doesn't seem too possible to get a meaningful source location for a 'cleanup' destructor, so those are still 'frontend' level errors unfortunately. A fixme was added to the test to cover that situation.
2020-04-01[clang][xray] Add xray attributes to functions without decls tooIan Levesque1-44/+43
Summary: This allows instrumenting things like global initializers Reviewers: dberris, MaskRay, smeenai Subscribers: cfe-commits, johnislarry Tags: #clang Differential Revision: https://reviews.llvm.org/D77191
2020-03-15[Clang][SVE] Parse builtin type string for scalable vectorsSander de Smalen1-4/+6
This patch adds 'q' to mean 'scalable vector' in the builtin type string, and for SVE will return the matching builtin type as defined in the C/C++ language extensions for SVE. This patch also adds some scaffolding to generate the arm_sve.h header file, and some builtin definitions (+CodeGen) to be able to implement some simple masked load intrinsics that use the ACLE types, such as: svint8_t test_svld1_s8(svbool_t pg, const int8_t *base) { return svld1_s8(pg, base); } Reviewers: efriedma, rjmccall, rovka, rsandifo-arm, rengolin Reviewed By: efriedma Tags: #clang Differential Revision: https://reviews.llvm.org/D75298
2020-02-16[OpenCL][CUDA][HIP][SYCL] Add norecurseYaxun (Sam) Liu1-4/+14
norecurse function attr indicates the function is not called recursively directly or indirectly. Add norecurse to OpenCL functions, SYCL functions in device compilation and CUDA/HIP kernels. Although there is LLVM pass adding norecurse to functions, it only works for whole-program compilation. Also FE adding norecurse can make that pass run faster since functions with norecurse do not need to be checked again. Differential Revision: https://reviews.llvm.org/D73651
2020-02-13[AsmPrinter] De-capitalize all AsmPrinter::Emit* but EmitInstructionFangrui Song1-5/+5
Similar to rL328848.
2020-02-12Reapply "[OpenMP][IRBuilder] Perform finalization (incl. outlining) late"Johannes Doerfert1-0/+9
Reapply 8a56d64d7620b3764f10f03f3a1e307fcdd72c2f with minor fixes. The problem was that cancellation can cause new edges to the parallel region exit block which is not outlined. The CodeExtractor will encode the information which "exit" was taken as a return value. The fix is to ensure we do not return any value from the outlined function, to prevent control to value conversion we ensure a single exit block for the outlined region. This reverts commit 3aac953afa34885a72df96f2b703b65f85cbb149.
2020-02-12Revert "[OpenMP][IRBuilder] Perform finalization (incl. outlining) late"Johannes Doerfert1-9/+0
This reverts commit 8a56d64d7620b3764f10f03f3a1e307fcdd72c2f. Will be recommitted once the clang test problem is addressed.
2020-02-12[OpenMP][IRBuilder] Perform finalization (incl. outlining) lateJohannes Doerfert1-0/+9
In order to fix PR44560 and to prepare for loop transformations we now finalize a function late, which will also do the outlining late. The logic is as before but the actual outlining step happens now after the function was fully constructed. Once we have loop transformations we can apply them in the finalize step before the outlining. Reviewed By: JonChesterfield Differential Revision: https://reviews.llvm.org/D74372
2020-02-11[xray][clang] Always add xray-skip-entry/exit and xray-ignore-loops attrsIan Levesque1-10/+12
The function attributes xray-skip-entry, xray-skip-exit, and xray-ignore-loops were only being applied if a function had an xray-instrument attribute, but they should apply if xray is enabled globally too. Differential Revision: https://reviews.llvm.org/D73842
2020-01-23[Driver][CodeGen] Support -fpatchable-function-entry=N,M and ↵Fangrui Song1-6/+11
__attribute__((patchable_function_entry(N,M))) where M>0 Reviewed By: nickdesaulniers Differential Revision: https://reviews.llvm.org/D73072
2020-01-17[xray] Allow instrumenting only function entry and/or only function exitIan Levesque1-1/+11
Extend -fxray-instrumentation-bundle to split function-entry and function-exit into two separate options, so that it is possible to instrument only function entry or only function exit. For use cases that only care about one or the other this will save significant overhead and code size. Differential Revision: https://reviews.llvm.org/D72890
2020-01-17[clang][xray] Add -fxray-ignore-loops optionIan Levesque1-0/+3
XRay allows tuning by minimum function size, but also always instruments functions with loops in them. If the minimum function size is set to a large value the loop instrumention ends up causing most functions to be instrumented anyway. This adds a new flag, -fxray-ignore-loops, to disable the loop detection logic. Differential Revision: https://reviews.llvm.org/D72873
2020-01-13[DebugInfo] Add another level to DebugInfoKind called ConstructorAmy Huang1-1/+1
The option will limit debug info by only emitting complete class type information when its constructor is emitted. This patch changes comparisons with LimitedDebugInfo to use the new level instead. Differential Revision: https://reviews.llvm.org/D72427
2020-01-10[Driver][CodeGen] Add -fpatchable-function-entry=N[,0]Fangrui Song1-0/+3
In the backend, this feature is implemented with the function attribute "patchable-function-entry". Both the attribute and XRay use TargetOpcode::PATCHABLE_FUNCTION_ENTER, so the two features are incompatible. Reviewed By: ostannard, MaskRay Differential Revision: https://reviews.llvm.org/D72222
2020-01-10Support function attribute patchable_function_entryFangrui Song1-1/+7
This feature is generic. Make it applicable for AArch64 and X86 because the backend has only implemented NOP insertion for AArch64 and X86. Reviewed By: nickdesaulniers, aaron.ballman Differential Revision: https://reviews.llvm.org/D72221
2020-01-07[NFC] Use isX86() instead of getArch()Jim Lin1-4/+1
Summary: This is a clean up for https://reviews.llvm.org/D72247. Reviewers: MaskRay, craig.topper, jhenderson Reviewed By: MaskRay Subscribers: hiraditya, rupprecht, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72320
generated by cgit v1.1 at 2025-10-02 20:38:36 +0000