| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[clang][AArch64][SVE] Change SVE_VECTOR_OPERATORS macro for VLA vectors The __ARM_FEATURE_SVE_VECTOR_OPERATORS macro should be changed to indicate that this feature is now supported on VLA vectors as well as VLS vectors. There is a complementary PR to the ACLE spec here https://github.com/ARM-software/acle/pull/213 Reviewed By: peterwaller-arm Differential Revision: https://reviews.llvm.org/D131573 (cherry picked from commit 13a784f368ef062a7bd652829bcf8bbdd94dc659) | 3 年前 | |
[AArch64] Remove unused feature flags from AArch64TargetInfo This removes two feature flags from AArch64TargetInfo class: - HasHBC: this feature does not involve generating any IR intrinsics, so clang does not need to know about whether it is set - HasCrypto: this feature is deprecated in favor of finer grained features such as AES, SHA2, SHA3 and SM4. The associated ACLE macro __ARM_FEATURE_CRYPTO is thus no longer used. Differential Revision: https://reviews.llvm.org/D118757 | 4 年前 | |
[AMDGPU] Support for gfx940 fp8 conversions Differential Revision: https://reviews.llvm.org/D129902 | 3 年前 | |
[clang] Convert for_each to range-based for loops (NFC) | 3 年前 | |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 | 7 年前 | |
Introduce _BitInt, deprecate _ExtInt 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. | 4 年前 | |
[ARM][AArch64] Add missing v8.x checks Summary: This patch adds checks that were missing in clang for Armv8.5/6/7-A. These include: * ACLE macro defines for AArch32. * Handling of crypto and SM4, SHA and AES feature flags on clang's driver. Reviewers: dmgreen, SjoerdMeijer, tmatheson Differential Revision: https://reviews.llvm.org/D116153 | 4 年前 | |
[clang][ARM] Emit warnings when PACBTI-M is used with unsupported architectures Branch protection in M-class is supported by - Armv8.1-M.Main - Armv8-M.Main - Armv7-M Attempting to enable this for other architectures, either by command-line (e.g -mbranch-protection=bti) or by target attribute in source code (e.g. __attribute__((target("branch-protection=..."))) ) will generate a warning. In both cases function attributes related to branch protection will not be emitted. Regardless of the warning, module level attributes related to branch protection will be emitted when it is enabled via the command-line. The following people also contributed to this patch: - Victor Campos Reviewed By: chill Differential Revision: https://reviews.llvm.org/D115501 | 4 年前 | |
[compiler-rt][builtins] Fix wrong ABI of AVR __mulqi3 & __mulhi3 Reviewed By: aykevl, dylanmckay Differential Revision: https://reviews.llvm.org/D125077 | 4 年前 | |
[clang][AVR] Implement standard calling convention for AVR and AVRTiny This patch implements avr-gcc's calling convention: https://gcc.gnu.org/wiki/avr-gcc#Calling_Convention Reviewed By: aykevl Differential Revision: https://reviews.llvm.org/D120720 | 4 年前 | |
[Basic] Use llvm::is_contained (NFC) | 4 年前 | |
[BPF] add support for 32 bit registers in inline asm Add "w" constraint type which allows selecting 32 bit registers. 32 bit registers were added in https://reviews.llvm.org/rGca31c3bb3ff149850b664838fbbc7d40ce571879. Differential Revision: https://reviews.llvm.org/D102118 | 5 年前 | |
[CSKY] Fix the conflict of default fpu features and -mfpu option The arch or cpu has its default fpu features and versions such as fpuv2_sf/fpuv3_sf. And there is also -mfpu option to specify and override fpu version and features. For example, C860 has fpuv3_sf/fpuv3_df feature as default, when -mfpu=fpv2 is given, fpuv3_sf/fpuv3_df is replaced with fpuv2_sf/fpuv2_df. | 4 年前 | |
[clang] Remove redundant virtual specifies (NFC) Identified with modernize-use-override. | 3 年前 | |
Add clang DirectX target support This change adds a stub DirectX target for clang to enable targeting dxil targets. Reviewed By: pete Differential Revision: https://reviews.llvm.org/D122085 | 4 年前 | |
[HLSL] Enable half type for hlsl. HLSL supports half type. When enable-16bit-types is not set, half will be treated as float. When enable-16bit-types is set, half will be treated like real 16bit float type and map to llvm half type. Also change CXXABI to Microsoft to match dxc behavior. The mangle name for half is "$f16@" when half is treat as native half type and "$halff@" when treat as float. In AST, half is still half. The special thing is done at clang codeGen, when NativeHalfType is false, half will translated into float. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D124790 | 3 年前 | |
[Hexagon] Driver/preprocessor options for Hexagon v69 | 4 年前 | |
Introduce _BitInt, deprecate _ExtInt 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. | 4 年前 | |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 | 7 年前 | |
Introduce _BitInt, deprecate _ExtInt 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. | 4 年前 | |
[NFC] Remove reference to file deleted by D100981. | 5 年前 | |
[NFC] Remove reference to file deleted by D100981. | 5 年前 | |
Remove redundant string initialization (NFC) Identified with readability-redundant-string-init. | 4 年前 | |
[cfe] Support target-specific escaped character in inline asm GCC allows each target to define a set of non-letter and non-digit escaped characters for inline assembly that will be replaced by another string (They call this "punctuation" characters. The existing "%%" and "%{" -- replaced by '%' and '{' at the end -- can be seen as special cases shared by all targets). This patch implements this feature by adding a new hook in TargetInfo. Differential Revision: https://reviews.llvm.org/D103036 | 5 年前 | |
[MSP430] Actualize the toolchain description Reviewed By: krisb Differential Revision: https://reviews.llvm.org/D81676 | 5 年前 | |
[MSP430] Update register names When writing a unit test on replacing standard epilogue sequences with BR __mspabi_func_epilog_<N>, by manually asm-clobbering rN - r10 for N = 4..10, everything worked well except for seeming inability to clobber r4. The problem was that MSP430 code generator of LLVM used an obsolete name FP for that register. Things were worse because when llc read an unknown register name, it silently ignored it. That is, I cannot use fp register name from the C code because Clang does not accept it (exactly like GCC). But the accepted name r4 is not recognised by llc (it can be used in listings passed to llvm-mc and even fp is replace to r4 by llvm-mc). So I can specify any of fp or r4 for the string literal of asm(...) but nothing in the clobber list. This patch replaces MSP430::FP with MSP430::R4 in the backend code (even [MSP430 EABI](http://www.ti.com/lit/an/slaa534/slaa534.pdf) doesn't mention FP as a register name). The R0 - R3 registers, on the other hand, are left as is in the backend code (after all, they have some special meaning on the ISA level). It is just ensured clang is renaming them as expected by the downstream tools. There is probably not much sense in **marking them clobbered** but rename them //just in case// for use at potentially different contexts. Differential Revision: https://reviews.llvm.org/D82184 | 5 年前 | |
[Basic] Use llvm::is_contained (NFC) | 4 年前 | |
Introduce _BitInt, deprecate _ExtInt 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. | 4 年前 | |
[OpenMP] Add __CUDA_ARCH__ definition when offloading with OpenMP Currently we define the __CUDA_ARCH__ macro only in CUDA mode. This patch allows us to use this macro in OpenMP-offloading mode when targeting NVPTX. Reviewed By: tra, tianshilei1992 Differential Revision: https://reviews.llvm.org/D125256 | 4 年前 | |
Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17" This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2. - It conflicts with the existing llvm::size in STLExtras, which will now never be called. - Calling it without llvm:: breaks C++17 compat | 4 年前 | |
[clang] Use value_or instead of getValueOr (NFC) | 3 年前 | |
[PS5] Add PS5OSTargetInfo class, update affected tests | 4 年前 | |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 | 7 年前 | |
Introduce _BitInt, deprecate _ExtInt 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. | 4 年前 | |
[clang][AIX] Add option to control quadword lock free atomics ABI on AIX We are supporting quadword lock free atomics on AIX. For the situation that users on AIX are using a libatomic that is lock-based for quadword types, we can't enable quadword lock free atomics by default on AIX in case user's new code and existing code accessing the same shared atomic quadword variable, we can't guarentee atomicity. So we need an option to enable quadword lock free atomics on AIX, thus we can build a quadword lock-free libatomic(also for advanced users considering atomic performance critical) for users to make the transition smooth. Reviewed By: shchenz Differential Revision: https://reviews.llvm.org/D127189 | 3 年前 | |
[PowerPC] Enable CR bits support for Power8 and above. This patch turns on support for CR bit accesses for Power8 and above. The reason why CR bits are turned on as the default for Power8 and above is that because later architectures make use of builtins and instructions that require CR bit accesses (such as the use of setbc in the vector string isolate predicate and bcd builtins on Power10). This patch also adds the clang portion to allow for turning on CR bits in the front end if the user so desires to. Differential Revision: https://reviews.llvm.org/D124060 | 4 年前 | |
[RISCV][Clang] Add support for Zmmul extension This patch implements recently ratified extension Zmmul, a subextension of M (Integer Multiplication and Division) consisting only multiplication part of it. Differential Revision: https://reviews.llvm.org/D103313 Reviewed By: craig.topper, jrtc27, asb | 3 年前 | |
[RISCV] Fix int16 -> __fp16 conversion code gen clang emit wrong code sequence for int16(short) to __fp16 conversion, and that should fix the code gen directly is the right way I think, but I found there is a FIXME comment in clang/Basic/TargetInfo.h say that's should be removed in future so I think just let swich to using generic LLVM IR rather than llvm.convert.to.fp16 intrinsics code gen path is enough. /// Check whether llvm intrinsics such as llvm.convert.to.fp16 should be used /// to convert to and from __fp16. /// FIXME: This function should be removed once all targets stop using the /// conversion intrinsics. virtual bool useFP16ConversionIntrinsics() const { return true; } Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D124509 | 4 年前 | |
[SPIR-V] Add SPIR-V triple and clang target info. Add new triple and target info for ‘spirv32’ and ‘spirv64’ and, thus, enabling clang (LLVM IR) code emission to SPIR-V target. The target for SPIR-V is mostly reused from SPIR by derivation from a common base class since IR output for SPIR-V is mostly the same as SPIR. Some refactoring are made accordingly. Added and updated tests for parts that are different between SPIR and SPIR-V. Patch by linjamaki (Henry Linjamäki)! Differential Revision: https://reviews.llvm.org/D109144 | 4 年前 | |
[CUDA][SPIRV] Assign global address space to CUDA kernel arguments (resubmit https://reviews.llvm.org/D119207 after fixing the test for some build settings) This patch converts CUDA pointer kernel arguments with default address space to CrossWorkGroup address space (__global in OpenCL). This is because Generic or Function (OpenCL's private) is not supported as storage class for kernel pointer types. Differential revision: https://reviews.llvm.org/D120366 | 4 年前 | |
[Sparc] Don't define __sparcv9 and __sparcv9__ when targeting V8+ Currently, clang defines the three macros __sparcv9, __sparcv9__ and __sparc_v9__ when targeting the V8+ baseline, i.e. using the V9 instruction set on a 32-bit target. Since neither gcc nor SolarisStudio define __sparcv9 and __sparcv9__ when targeting V8+, some existing code such as the glibc breaks when defining either of these two macros on a 32-bit target as they are used to detect a 64-bit target. Update the tests accordingly. Fixes PR49562. Reviewed By: jrtc27, MaskRay, hvdijk Differential Revision: https://reviews.llvm.org/D98574 | 4 年前 | |
Introduce _BitInt, deprecate _ExtInt 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. | 4 年前 | |
Support z16 processor name The recently announced IBM z16 processor implements the architecture already supported as "arch14" in LLVM. This patch adds support for "z16" as an alternate architecture name for arch14. | 4 年前 | |
[SystemZ] Enable -mtune= option in clang. https://reviews.llvm.org/D128910 enabled handling of attribute "tune-cpu" in LLVM. This PR now enables option -mtune in clang, which then generates the new attribute. Reviewed By: uweigand Differential Revision: https://reviews.llvm.org/D129562 | 3 年前 | |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636 | 7 年前 | |
[SYCL] Enable opencl_global_[host,device] attributes for SYCL Differential Revision: https://reviews.llvm.org/D100396 | 5 年前 | |
[Clang][VE] Add vector load intrinsics Add vector load intrinsic instructions for VE. Reviewed By: simoll Differential Revision: https://reviews.llvm.org/D121049 | 4 年前 | |
[VE] Change clang to support SjLj Lowering We supports SjLj exception handling in the backend, so changing clang to allow lowering using SjLj exceptions. Update a regression test also. Reviewed By: simoll Differential Revision: https://reviews.llvm.org/D94076 | 5 年前 | |
[WebAssembly] Add new target feature in support of 'extended-const' proposal We don't yet do anything when this feature is enabled, this change just lays the ground work by accepting that there is such a feature. See https://github.com/WebAssembly/extended-const Differential Revision: https://reviews.llvm.org/D121151 | 4 年前 | |
[WebAssembly] Add new target feature in support of 'extended-const' proposal We don't yet do anything when this feature is enabled, this change just lays the ground work by accepting that there is such a feature. See https://github.com/WebAssembly/extended-const Differential Revision: https://reviews.llvm.org/D121151 | 4 年前 | |
[X86][BF16] Enable __bf16 for x86 targets. X86 psABI has updated to support __bf16 type, the ABI of which is the same as FP16. See https://discourse.llvm.org/t/patch-add-optional-bfloat16-support/63149 Reviewed By: pengfei Differential Revision: https://reviews.llvm.org/D130964 (cherry picked from commit e4888a37d36780872d685c68ef8b26b2e14d6d39) | 3 年前 | |
[X86][BF16] Enable __bf16 for x86 targets. X86 psABI has updated to support __bf16 type, the ABI of which is the same as FP16. See https://discourse.llvm.org/t/patch-add-optional-bfloat16-support/63149 Reviewed By: pengfei Differential Revision: https://reviews.llvm.org/D130964 (cherry picked from commit e4888a37d36780872d685c68ef8b26b2e14d6d39) | 3 年前 | |
[clang][XCore] Define __xcore__ for XCore target. The headers shipped with the XMOS XCore compiler expect __xcore__ to be defined. The __XS1B__ macro, already defined, is for the default subtarget. No other targets affected. | 5 年前 | |
Introduce _BitInt, deprecate _ExtInt 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. | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 7 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 7 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 7 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 7 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 4 年前 |