aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/TargetInfo.cpp
AgeCommit message (Collapse)AuthorFilesLines
2020-06-05[ARM] Add __bf16 as new Bfloat16 C TypeTies Stuij1-11/+47
Summary: This patch upstreams support for a new storage only bfloat16 C type. This type is used to implement primitive support for bfloat16 data, in line with the Bfloat16 extension of the Armv8.6-a architecture, as detailed here: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a The bfloat type, and its properties are specified in the Arm Architecture Reference Manual: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile In detail this patch: - introduces an opaque, storage-only C-type __bf16, which introduces a new bfloat IR type. This is part of a patch series, starting with command-line and Bfloat16 assembly support. The subsequent patches will upstream intrinsics support for BFloat16, followed by Matrix Multiplication and the remaining Virtualization features of the armv8.6-a architecture. The following people contributed to this patch: - Luke Cheeseman - Momchil Velikov - Alexandros Lamprineas - Luke Geeson - Simon Tatham - Ties Stuij Reviewers: SjoerdMeijer, rjmccall, rsmith, liutianle, RKSimon, craig.topper, jfb, LukeGeeson, fpetrogalli Reviewed By: SjoerdMeijer Subscribers: labrinea, majnemer, asmith, dexonsmith, kristof.beyls, arphaman, danielkiss, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D76077
2020-06-03[HIP] Change default --gpu-max-threads-per-block value to 1024Yaxun (Sam) Liu1-2/+6
Differential Revision: https://reviews.llvm.org/D76795
2020-06-01[SVE] Eliminate calls to default-false VectorType::get() from ClangChristopher Tetreault1-15/+16
Reviewers: efriedma, david-arm, fpetrogalli, ddunbar, rjmccall Reviewed By: fpetrogalli, rjmccall Subscribers: tschuett, rkruppe, psnobl, dmgreen, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80323
2020-05-19Fix X86_64 complex-returns for regcall.Erich Keane1-6/+7
D35259 introduced a case where complex types of non-long-double would result in FI.getReturnInfo() to not be initialized properly. This resulted in a crash under some very specific circumstances when dereferencing the LLVMContext. This patch makes sure that these types have the intended getReturnInfo initialization.
2020-05-19[clang][AIX] Implement ABIInfo and TargetCodeGenInfo for AIXjasonliu1-96/+239
Summary: Created AIXABIInfo and AIXTargetCodeGenInfo for AIX ABI. Reviewed By: Xiangling_L, ZarkoCA Differential Revision: https://reviews.llvm.org/D79035
2020-05-18[RISCV] Fix passing two floating-point values in complex separately by two ↵Jim Lin1-1/+2
GPRs on RV64 Summary: This patch fixed the error of counting the remaining FPRs. Complex floating-point values should be passed by two FPRs for the hard-float ABI. If no two FPRs are available, it should be passed via a 64-bit GPR (fp+fp). `ArgFPRsLeft` is only decreased one while the type is complex floating-point. It causes two floating-point values in the complex are passed separately by two GPRs. Reviewers: asb, luismarques, lenary Reviewed By: asb Subscribers: rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, s.egerton, pzheng, sameer.abuasal, apazos, evandro, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D79770
2020-05-13[NFC] Code cleanup in TargetInfo.cppShengchen Kan1-2/+2
Fix the signed/unsigned mismatch issue
2020-05-09Fix typoMatt Arsenault1-1/+1
2020-05-06Implement _ExtInt ABI for all ABIs in Clang, enable type for ABIsErich Keane1-59/+189
This is the result of an audit of all of the ABIs in clang to implement and enable the type for those targets. Additionally, this finds an issue with integer-promotion passing for a few platforms when using _ExtInt of < int, so this also corrects that resulting in signext/zeroext being on a params of those types in some platforms. Differential Revisions: https://reviews.llvm.org/D79118
2020-05-04Test commit. Modified comment to add a period at the end.Zarko1-1/+1
2020-04-30[NFC][clang] Replace raw new/delete with unique_ptr to store ABIInfo in ↵jasonliu1-29/+30
TargetCodeGenInfo Use unique_ptr to manage the lifetime of ABIInfo member inside TargetCodeGenInfo. Reviewed By: hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D79033
2020-04-29Fix x86/x86_64 calling convention for _ExtIntErich Keane1-3/+34
After speaking with Craig Topper about some recent defects, he pointed out that _ExtInts should be passed indirectly if larger than the largest int register, and like ints when smaller than that. This patch implements that. Note that this changed the way vaargs worked quite a bit, but they still work. Differential Revision: https://reviews.llvm.org/D78785
2020-04-21[PowerPC] Add clang -msvr4-struct-return for 32-bit ELFJustin Hibbits1-7/+75
Summary: Change the default ABI to be compatible with GCC. For 32-bit ELF targets other than Linux, Clang now returns small structs in registers r3/r4. This affects FreeBSD, NetBSD, OpenBSD. There is no change for 32-bit Linux, where Clang continues to return all structs in memory. Add clang options -maix-struct-return (to return structs in memory) and -msvr4-struct-return (to return structs in registers) to be compatible with gcc. These options are only for PPC32; reject them on PPC64 and other targets. The options are like -fpcc-struct-return and -freg-struct-return for X86_32, and use similar code. To actually return a struct in registers, coerce it to an integer of the same size. LLVM may optimize the code to remove unnecessary accesses to memory, and will return i32 in r3 or i64 in r3:r4. Fixes PR#40736 Patch by George Koehler! Reviewed By: jhibbits, nemanjai Differential Revision: https://reviews.llvm.org/D73290
2020-04-14[SVE] Remove calls to getBitWidth from clangChristopher Tetreault1-2/+3
Reviewers: efriedma Reviewed By: efriedma Subscribers: tschuett, rkruppe, psnobl, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77903
2020-04-13Clean up usages of asserting vector getters in TypeChristopher Tetreault1-1/+1
Summary: Remove usages of asserting vector getters in Type in preparation for the VectorType refactor. The existence of these functions complicates the refactor while adding little value. Reviewers: sdesmalen, efriedma, krememek Reviewed By: sdesmalen, efriedma Subscribers: dexonsmith, Charusso, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77257
2020-04-07[hip] Remove `hip_pinned_shadow`.Michael Liao1-13/+3
Summary: - Use `device_builtin_surface` and `device_builtin_texture` for surface/texture reference support. So far, both the host and device use the same reference type, which could be revised later when interface/implementation is stablized. Reviewers: yaxunl Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77583
2020-04-02[clang] Move branch-protection from CodeGenOptions to LangOptionsDaniel Kiss1-6/+8
Summary: Reason: the option has an effect on preprocessing. Also see thread: http://lists.llvm.org/pipermail/cfe-dev/2020-March/065014.html Reviewers: chill, efriedma Reviewed By: efriedma Subscribers: efriedma, danielkiss, cfe-commits, kristof.beyls Tags: #clang Differential Revision: https://reviews.llvm.org/D77131
2020-03-27[cuda][hip] Add CUDA builtin surface/texture reference support.Michael Liao1-9/+82
Summary: - Re-commit after fix Sema checks on partial template specialization. Reviewers: tra, rjmccall, yaxunl, a.sidorin Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D76365
2020-03-27Revert "[cuda][hip] Add CUDA builtin surface/texture reference support."Artem Belevich1-82/+9
This reverts commit 6a9ad5f3f4ac66f0cae592e911f4baeb6ee5eca6. The patch breaks CUDA copmilation. Differential Revision: https://reviews.llvm.org/D76365
2020-03-26[Hexagon] Add support for Linux/Musl ABI (part 2)Sid Manning1-12/+294
A continuation of https://reviews.llvm.org/D72701. This adds support needed in clang. Differential Revision: https://reviews.llvm.org/D75638
2020-03-26[cuda][hip] Add CUDA builtin surface/texture reference support.Michael Liao1-9/+82
Summary: - Even though the bindless surface/texture interfaces are promoted, there are still code using surface/texture references. For example, [PR#26400](https://bugs.llvm.org/show_bug.cgi?id=26400) reports the compilation issue for code using `tex2D` with texture references. For better compatibility, this patch proposes the support of surface/texture references. - Due to the absent documentation and magic headers, it's believed that `nvcc` does use builtins for texture support. From the limited NVVM documentation[^nvvm] and NVPTX backend texture/surface related tests[^test], it's believed that surface/texture references are supported by replacing their reference types, which are annotated with `device_builtin_surface_type`/`device_builtin_texture_type`, with the corresponding handle-like object types, `cudaSurfaceObject_t` or `cudaTextureObject_t`, in the device-side compilation. On the host side, that global handle variables are registered and will be established and updated later when corresponding binding/unbinding APIs are called[^bind]. Surface/texture references are most like device global variables but represented in different types on the host and device sides. - In this patch, the following changes are proposed to support that behavior: + Refine `device_builtin_surface_type` and `device_builtin_texture_type` attributes to be applied on `Type` decl only to check whether a variable is of the surface/texture reference type. + Add hooks in code generation to replace that reference types with the correponding object types as well as all accesses to them. In particular, `nvvm.texsurf.handle.internal` should be used to load object handles from global reference variables[^texsurf] as well as metadata annotations. + Generate host-side registration with proper template argument parsing. --- [^nvvm]: https://docs.nvidia.com/cuda/pdf/NVVM_IR_Specification.pdf [^test]: https://raw.githubusercontent.com/llvm/llvm-project/master/llvm/test/CodeGen/NVPTX/tex-read-cuda.ll [^bind]: See section 3.2.11.1.2 ``Texture reference API` in [CUDA C Programming Guide](https://docs.nvidia.com/cuda/pdf/CUDA_C_Programming_Guide.pdf). [^texsurf]: According to NVVM IR, `nvvm.texsurf.handle` should be used. But, the current backend doesn't have that supported. We may revise that later. Reviewers: tra, rjmccall, yaxunl, a.sidorin Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D76365
2020-03-13[HIP] Mark kernels with uniform-work-group-size=trueYaxun (Sam) Liu1-0/+4
Differential Revision: https://reviews.llvm.org/D76076
2020-02-19[MS] Mark vectorcall FP and vector args inregReid Kleckner1-1/+1
This has no effect on how LLVM passes the arguments, but it prevents rewriteWithInAlloca from thinking that these parameters should be part of the inalloca pack. Follow-up to D72114 Reviewed By: erichkeane Differential Revision: https://reviews.llvm.org/D74452
2020-02-12Fix `-Wunused-variable` warning. NFC.Michael Liao1-1/+1
2020-02-11Re-land "[MS] Overhaul how clang passes overaligned args on x86_32"Reid Kleckner1-24/+50
This brings back 2af74e27ed7d0832cbdde9cb969aaca7a42e99f9 and reverts eaabaf7e04fe98990a8177a3e053346395efde1c. The changes were correct, the code that was broken contained an ODR violation that assumed that these types are passed equivalently: struct alignas(uint64_t) Wrapper { uint64_t P }; void f(uint64_t p); void f(Wrapper p); MSVC does not pass them the same way, and so clang-cl should not pass them the same way either.
2020-02-11[Hexagon] Fix ABI info for returning HVX vectorsKrzysztof Parzyszek1-32/+32
2020-02-04[WebAssembly] Add experimental multivalue calling ABIThomas Lively1-6/+36
Summary: For now, this ABI simply expands all possible aggregate arguments and returns all possible aggregates directly. This ABI will change rapidly as we prototype and benchmark a new ABI that takes advantage of multivalue return and possibly other changes from the MVP ABI. Reviewers: aheejin, dschuff Subscribers: sbc100, jgravelle-google, sunfish, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72972
2020-02-04[SystemZ] Support -msoft-floatJonas Paulsson1-7/+12
This is needed when building the Linux kernel. Review: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D72189
2020-01-28Revert "[MS] Overhaul how clang passes overaligned args on x86_32"Hans Wennborg1-50/+24
It broke some Chromium tests, so let's revert until it can be fixed; see https://crbug.com/1046362 This reverts commit 2af74e27ed7d0832cbdde9cb969aaca7a42e99f9.
2020-01-23[MS] Overhaul how clang passes overaligned args on x86_32Reid Kleckner1-24/+50
MSVC 2013 would refuse to pass highly aligned things (typically vectors and aggregates) by value. Users would receive this error: t.cpp(11) : error C2719: 'w': formal parameter with __declspec(align('32')) won't be aligned t.cpp(11) : error C2719: 'q': formal parameter with __declspec(align('32')) won't be aligned However, in MSVC 2015, this behavior was changed, and highly aligned things are now passed indirectly. To avoid breaking backwards incompatibility, objects that do not have a *required* high alignment (i.e. double) are still passed directly, even though they are not naturally aligned. This change implements the new behavior of passing things indirectly. The new behavior is: - up to three vector parameters can be passed in [XYZ]MM0-2 - remaining arguments with required alignment greater than 4 bytes are passed indirectly Previously, MSVC never passed things truly indirectly, meaning clang would always apply the byval attribute to indirect arguments. We had to go to the trouble of adding inalloca so that non-trivially copyable C++ types could be passed in place without copying the object representation. When inalloca was added, we asserted that all arguments passed indirectly must use byval. With this change, that assert no longer holds, and I had to update inalloca to handle that case. The implicit sret pointer parameter was already handled this way, and this change generalizes some of that logic to arguments. There are two cases that this change leaves unfixed: 1. objects that are non-trivially copyable *and* overaligned 2. vectorcall + inalloca + vectors For case 1, I need to touch C++ ABI code in MicrosoftCXXABI.cpp, so I want to do it in a follow-up. For case 2, my fix is one line, but it will require updating IR tests to use lots of inreg, so I wanted to separate it out. Related to D71915 and D72110 Fixes most of PR44395 Reviewed By: rjmccall, craig.topper, erichkeane Differential Revision: https://reviews.llvm.org/D72114
2020-01-23[Alignment][NFC] Use Align with CreateAlignedStoreGuillaume Chatelet1-2/+2
Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet, bollu Subscribers: arsenm, jvesely, nhaehnle, hiraditya, kerbowa, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D73274
2020-01-14[X86] ABI compat bugfix for MSVC vectorcallReid Kleckner1-75/+61
Summary: Before this change, X86_32ABIInfo::classifyArgument would be called twice on vector arguments to vectorcall functions. This function has side effects to track GPR register usage, and this would lead to incorrect GPR usage in some cases. The specific case I noticed is from running out of XMM registers with mixed FP and vector arguments and no aggregates of any kind. Consider this prototype: void __vectorcall vectorcall_indirect_vec( double xmm0, double xmm1, double xmm2, double xmm3, double xmm4, __m128 xmm5, __m128 ecx, int edx, __m128 mem); classifyArgument has no effects when called on a plain FP type, but when called on a vector type, it modifies FreeRegs to model GPR consumption. However, this should not happen during the vector call first pass. I refactored the code to unify vectorcall HVA logic with regcall HVA logic. The conventions pass HVAs in registers differently (expanded vs. not expanded), but if they do not fit in registers, they both pass them indirectly by address. Reviewers: erichkeane, craig.topper Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72110
2020-01-14[RISCV] Fix ILP32D lowering for double+double/double+int return typesJames Clarke1-5/+15
Summary: Previously, since these aggregates are > 2*XLen, Clang would think they were being returned indirectly and thus would decrease the number of available GPRs available by 1. For long argument lists this could lead to a struct argument incorrectly being passed indirectly. Reviewers: asb, lenary Reviewed By: asb, lenary Subscribers: luismarques, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, sameer.abuasal, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69590
2020-01-07[HIP] Add option --gpu-max-threads-per-block=nYaxun (Sam) Liu1-2/+5
Add this option to change the default launch bounds. Differential Revision: https://reviews.llvm.org/D71221
2019-12-22[ms] [X86] Use "P" modifier on operands to call instructions in inline X86 ↵Eric Astor1-0/+4
assembly. Summary: This is documented as the appropriate template modifier for call operands. Fixes PR44272, and adds a regression test. Also adds support for operand modifiers in Intel-style inline assembly. Reviewers: rnk Reviewed By: rnk Subscribers: merge_guards_bot, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71677
2019-12-11[WebAssembly] Add new `export_name` clang attribute for controlling wasm ↵Sam Clegg1-0/+6
export names This is equivalent to the existing `import_name` and `import_module` attributes which control the import names in the final wasm binary produced by lld. This maps the existing This attribute currently requires a string rather than using the symbol name for a couple of reasons: 1. Avoid confusion with static and dynamic linking which is based on symbol name. Exporting a function from a wasm module using this directive is orthogonal to both static and dynamic linking. 2. Avoids name mangling. Differential Revision: https://reviews.llvm.org/D70520
2019-12-09Avoid Attr.h includes, CodeGen editionReid Kleckner1-1/+2
This saves around 20 includes of Attr.h. Not much.
2019-12-09[Attr] Move ParsedTargetAttr out of the TargetAttr classCraig Topper1-1/+1
Need to forward declare it in ASTContext.h for D68627, so it can't be a nested struct. Differential Revision: https://reviews.llvm.org/D71159
2019-12-03[NFC] Pass a reference to CodeGenFunction to methods of LValue andAkira Hatanaka1-1/+1
AggValueSlot This reapplies 8a5b7c35709d9ce1f44a99f0c5b084bf2696ea17 after a null dereference bug in CGOpenMPRuntime::emitUserDefinedMapper. Original commit message: This is needed for the pointer authentication work we plan to do in the near future. https://github.com/apple/llvm-project/blob/a63a81bd9911f87a0b5dcd5bdd7ccdda7124af87/clang/docs/PointerAuthentication.rst
2019-12-03Revert "[NFC] Pass a reference to CodeGenFunction to methods of LValue and"Akira Hatanaka1-1/+1
This reverts commit 8a5b7c35709d9ce1f44a99f0c5b084bf2696ea17. This seems to have broken UBSan because of a null dereference.
2019-12-03[NFC] Pass a reference to CodeGenFunction to methods of LValue andAkira Hatanaka1-1/+1
AggValueSlot This is needed for the pointer authentication work we plan to do in the near future. https://github.com/apple/llvm-project/blob/a63a81bd9911f87a0b5dcd5bdd7ccdda7124af87/clang/docs/PointerAuthentication.rst
2019-11-15Implement target(branch-protection) attribute for AArch64Momchil Velikov1-6/+21
This patch implements `__attribute__((target("branch-protection=...")))` in a manner, compatible with the analogous GCC feature: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/AArch64-Function-Attributes.html#AArch64-Function-Attributes Differential Revision: https://reviews.llvm.org/D68711
2019-11-12AArch64: add arm64_32 support to Clang.Tim Northover1-12/+26
2019-11-05[hip] Enable pointer argument lowering through coercing type.Michael Liao1-3/+47
Reviewers: tra, rjmccall, yaxunl Subscribers: jvesely, nhaehnle, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69826
2019-10-25[hip] Allow the declaration of functions with variadic arguments in HIP.Michael Liao1-0/+7
Summary: - As variadic parameters have the lowest rank in overload resolution, without real usage of `va_arg`, they are commonly used as the catch-all fallbacks in SFINAE. As the front-end still reports errors on calls to `va_arg`, the declaration of functions with variadic arguments should be allowed in general. Reviewers: jlebar, tra, yaxunl Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69389
2019-10-08Remove an useless allocation (from by clang-analyzer/scan-build)Sylvestre Ledru1-1/+1
https://llvm.org/reports/scan-build/report-TargetInfo.cpp-detectFPCCEligibleStruct-9-1.html#EndPath llvm-svn: 374032
2019-10-07Codegen - silence static analyzer getAs<> null dereference warnings. NFCI.Simon Pilgrim1-1/+1
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 373918
2019-10-03Silence static analyzer getAs<RecordType> null dereference warnings. NFCI.Simon Pilgrim1-4/+4
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<RecordType> directly and if not assert will fire for us. llvm-svn: 373584
2019-09-30[Alignment][NFC] Remove AllocaInst::setAlignment(unsigned)Guillaume Chatelet1-1/+1
Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, arsenm, jvesely, nhaehnle, eraman, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68141 llvm-svn: 373207
2019-09-06[X86] Prevent passing vectors of __int128 as <X x i128> in llvm IRCraig Topper1-2/+40
As far as I can tell, gcc passes 256/512 bit vectors __int128 in memory. And passes a vector of 1 _int128 in an xmm register. The backend considers <X x i128> as an illegal type and will scalarize any arguments with that type. So we need to coerce the argument types in the frontend to match to avoid the illegal type. I'm restricting this to change to Linux and NetBSD based on the how similar ABI changes have been handled in the past. PS4, FreeBSD, and Darwin are unaffected. I've also added a new -fclang-abi-compat version to restore the old behavior. This issue was identified in PR42607. Though even with the types changed, we still seem to be doing some unnecessary stack realignment. llvm-svn: 371169
generated by cgit v1.1 at 2025-10-13 08:15:49 +0000