aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Basic/TargetInfo.cpp
AgeCommit message (Collapse)AuthorFilesLines
2022-06-09clang: Introduce -fexperimental-max-bitint-widthMatthias Gehre1-0/+6
This splits of the introduction of -fexperimental-max-bitint-width from https://reviews.llvm.org/D122234 because that PR is still blocked on discussions on the backend side. I was asked [0] to upstream at least the flag. [0] https://github.com/llvm/llvm-project/commit/09854f2af3b914b616f29cb640bede3a27cf7c4e#commitcomment-75116619 Differential Revision: https://reviews.llvm.org/D127287
2022-04-22[Clang] Fix the guaranteed alignment of memory returned by malloc/new on OpenBSDMark Kettenis1-3/+3
The guaranteed alignment is 16 bytes on OpenBSD.
2022-02-14[X86][MS] Add 80bit long double support for WindowsPhoebe Wang1-0/+14
MSVC currently doesn't support 80 bits long double. But ICC does support it on Windows. Besides, there're also some users asked for this feature. We can find the discussions from stackoverflow, msdn etc. Given Clang has already support `-mlong-double-80`, extending it to support for Windows seems worthwhile. Reviewed By: rnk, erichkeane Differential Revision: https://reviews.llvm.org/D115441
2022-01-27[OpenCL] Add support of __opencl_c_device_enqueue feature macro.Anton Zabaznov1-0/+2
This feature requires support of __opencl_c_generic_address_space and __opencl_c_program_scope_global_variables so diagnostics for that is provided as well. Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D115640
2022-01-13[clang] Fix function pointer address spaceElizabeth Andrews1-0/+1
Functions pointers should be created with program address space. This patch introduces program address space in TargetInfo. Targets with non-default (default is 0) address space for functions should explicitly set this value. This patch fixes a crash on lvalue reference to function pointer (in device code) when using oneAPI DPC++ compiler. Differential Revision: https://reviews.llvm.org/D111566
2022-01-02[clang] Remove redundant member initialization (NFC)Kazu Hirata1-1/+1
Identified with readability-redundant-member-init.
2021-11-03[X86][clang] Disable long double type for -mno-x87 optionAndrew Savonichev1-0/+2
This patch attempts to fix a compiler crash that occurs when long double type is used with -mno-x87 compiler option. The option disables x87 target feature, which in turn disables x87 registers, so CG cannot select them for x86_fp80 LLVM IR type. Long double is lowered as x86_fp80 for some targets, so it leads to a crash. The option seems to contradict the SystemV ABI, which requires long double to be represented as a 80-bit floating point, and it also requires to use x87 registers. To avoid that, `long double` type is disabled when -mno-x87 option is set. In addition to that, `float` and `double` also use x87 registers for return values on 32-bit x86, so they are disabled as well. Differential Revision: https://reviews.llvm.org/D98895
2021-11-02Fix complex types declared using mode TCElizabeth Andrews1-2/+5
This patch reverts incorrect IR introduced in commit d11ec6f67e45 [Clang] Enable IC/IF mode for __ibm128, for complex types declared using __attribute__((mode(TC))). TC corresponds to an unspecified 128-bit format, which on some targets is a double-double format (like __ibm128_t) and on others is float128_t. The bug in d11ec6f67e45 is that long double is only safe to use when it's known to be one of these formats. Differential Revision: https://reviews.llvm.org/D112975
2021-10-11[Clang] Enable IC/IF mode for __ibm128Qiu Chaofan1-5/+5
As for 128-bit floating points on PowerPC, compiler should have three machine modes: - IFmode, always IBM extended double - KFmode, always IEEE 754R 128-bit floating point - TFmode, matches the semantics for long double This commit adds support for IF mode with its complex variant, IC mode. Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D109950
2021-10-09[NFC] [Clang] Use global enum for explicit float modeQiu Chaofan1-10/+11
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-09-17[OpenCL] Supports optional pipe types in C++ for OpenCL 2021Justas Janickas1-3/+2
Adds support for a feature macro `__opencl_c_pipes` in C++ for OpenCL 2021 enabling a respective optional core feature from OpenCL 3.0. This change aims to achieve compatibility between C++ for OpenCL 2021 and OpenCL 3.0. Differential Revision: https://reviews.llvm.org/D109306
2021-09-06[Clang] Add __ibm128 type to represent ppc_fp128Qiu Chaofan1-0/+3
Currently, we have no front-end type for ppc_fp128 type in IR. PowerPC target generates ppc_fp128 type from long double now, but there's option (-mabi=(ieee|ibm)longdouble) to control it and we're going to do transition from IBM extended double-double ppc_fp128 to IEEE fp128 in the future. This patch adds type __ibm128 which always represents ppc_fp128 in IR, as what GCC did for that type. Without this type in Clang, compilation will fail if compiling against future version of libstdcxx (which uses __ibm128 in headers). Although all operations in backend for __ibm128 is done by software, only PowerPC enables support for it. There's something not implemented in this commit, which can be done in future ones: - Literal suffix for __ibm128 type. w/W is suitable as GCC documented. - __attribute__((mode(IF))) should be for __ibm128. - Complex __ibm128 type. Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D93377
2021-09-06[OpenCL] Supports optional generic address space semantics in C++ for OpenCL ↵Justas Janickas1-3/+4
2021 Adds support for a feature macro `__opencl_c_generic_adress_space` in C++ for OpenCL 2021 enabling a respective optional core feature from OpenCL 3.0. Testing is only performed in SemaOpenCL because generic address space functionality is yet to be implemented in C++ for OpenCL 2021. This change aims to achieve compatibility between C++ for OpenCL 2021 and OpenCL 3.0. Differential Revision: https://reviews.llvm.org/D108461
2021-07-30[OpenCL] Add support of __opencl_c_pipes feature macro.Anton Zabaznov1-3/+7
'pipe' keyword is introduced in OpenCL C 2.0: so do checks for OpenCL C version while parsing and then later on check for language options to construct actual pipe. This feature requires support of __opencl_c_generic_address_space, so diagnostics for that is provided as well. This is the same patch as in D106748 but with a tiny fix in checking of diagnostic messages. Also added tests when program scope global variables are not supported. Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D107154
2021-07-30Revert "[OpenCL] Add support of __opencl_c_pipes feature macro."Anton Zabaznov1-7/+3
This reverts commit d1e4b25756730576996457ba7324e9bf210e3693.
2021-07-30[OpenCL] Add support of __opencl_c_pipes feature macro.Anton Zabaznov1-3/+7
'pipe' keyword is introduced in OpenCL C 2.0: so do checks for OpenCL C version while parsing and then later on check for language options to construct actual pipe. This feature requires support of __opencl_c_generic_address_space, so diagnostics for that is provided as well. Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D106748
2021-07-13[OpenCL] Add support of __opencl_c_generic_address_space feature macroAnton Zabaznov1-0/+13
Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D103401
2021-06-30[clang][patch] Add builtin __arithmetic_fence and option fprotect-parensMelanie Blower1-0/+5
This patch adds a new clang builtin, __arithmetic_fence. The purpose of the builtin is to provide the user fine control, at the expression level, over floating point optimization when -ffast-math (-ffp-model=fast) is enabled. The builtin prevents the optimizer from rearranging floating point expression evaluation. The new option fprotect-parens has the same effect on parenthesized expressions, forcing the optimizer to respect the parentheses. Reviewed By: aaron.ballman, kpn Differential Revision: https://reviews.llvm.org/D100118
2021-06-29[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to ↵Melanie Blower1-1/+1
allow diagnostics on target-unsupported options Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D104729
2021-06-28Revert "[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass ↵Melanie Blower1-1/+1
DiagnosticsEngine to allow diagnostics on target-unsupported options" This reverts commit 2dbe1c675fe94eeb7973dcc25b049d25f4ca4fa0. More buildbot failures
2021-06-28[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to ↵Melanie Blower1-1/+1
allow diagnostics on target-unsupported options Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D104729
2021-06-28Revert "[clang][patch][fpenv] Add builtin __arithmetic_fence and option ↵Melanie Blower1-5/+0
fprotect-parens" This reverts commit 4f1238e44d803b145997fa984677a6c5cdf1f417. Buildbot fails on predecessor patch
2021-06-28Revert "[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass ↵Melanie Blower1-1/+1
DiagnosticsEngine to allow diagnostics on target-unsupported options" This reverts commit 2c02b0c3f45414ac6c64583e006a26113c028304. buildbot fails
2021-06-28[clang][patch][fpenv] Add builtin __arithmetic_fence and option fprotect-parensMelanie Blower1-0/+5
This patch adds a new clang builtin, __arithmetic_fence. The purpose of the builtin is to provide the user fine control, at the expression level, over floating point optimization when -ffast-math (-ffp-model=fast) is enabled. The builtin prevents the optimizer from rearranging floating point expression evaluation. The new option fprotect-parens has the same effect on parenthesized expressions, forcing the optimizer to respect the parentheses. Reviewed By: aaron.ballman, kpn Differential Revision: https://reviews.llvm.org/D100118
2021-06-28[clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to ↵Melanie Blower1-1/+1
allow diagnostics on target-unsupported options Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D104729
2021-05-18[clang][AVR] Redefine [u]int16_t to be compatible with avr-gccBen Shi1-0/+1
Reviewed By: efriedma Differential Revision: https://reviews.llvm.org/D102547
2021-05-13Support unwinding from inline assemblycynecx1-2/+2
I've taken the following steps to add unwinding support from inline assembly: 1) Add a new `unwind` "attribute" (like `sideeffect`) to the asm syntax: ``` invoke void asm sideeffect unwind "call thrower", "~{dirflag},~{fpsr},~{flags}"() to label %exit unwind label %uexit ``` 2.) Add Bitcode writing/reading support + LLVM-IR parsing. 3.) Emit EHLabels around inline assembly lowering (SelectionDAGBuilder + GlobalISel) when `InlineAsm::canThrow` is enabled. 4.) Tweak InstCombineCalls/InlineFunction pass to not mark inline assembly "calls" as nounwind. 5.) Add clang support by introducing a new clobber: "unwind", which lower to the `canThrow` being enabled. 6.) Don't allow unwinding callbr. Reviewed By: Amanieu Differential Revision: https://reviews.llvm.org/D95745
2021-04-27[clang/Basic] Make TargetInfo.h not use DataLayout againNico Weber1-3/+4
Reverts parts of https://reviews.llvm.org/D17183, but keeps the resetDataLayout() API and adds an assert that checks that datalayout string and user label prefix are in sync. Approach 1 in https://reviews.llvm.org/D17183#2653279 Reduces number of TUs build for 'clang-format' from 689 to 575. I also implemented approach 2 in D100764. If someone feels motivated to make us use DataLayout more, it's easy to revert this change here and go with D100764 instead. I don't plan on doing more work in this area though, so I prefer going with the smaller, more self-consistent change. Differential Revision: https://reviews.llvm.org/D100776
2021-03-29[SystemZ][z/OS] Set maximum value to truncate attribute aligned to for ↵Fanbo Meng1-0/+1
static variables on z/OS target On z/OS there is a hard limitation on on the maximum requestable alignment in aligned attribute for static variables. We need to truncate values greater than that. Reviewed By: abhina.sreeskantharajan Differential Revision: https://reviews.llvm.org/D98864
2021-03-26[SystemZ][z/OS] Ignore leading zero width bitfield alignment on z/OS targetFanbo Meng1-0/+1
Zero length bitfield alignment is not respected if they are leading members on z/OS target. Reviewed By: abhina.sreeskantharajan Differential Revision: https://reviews.llvm.org/D98890
2021-02-18[Clang][RISCV] Define RISC-V V builtin typesHsiangkai Wang1-0/+1
Add the types for the RISC-V V extension builtins. These types will be used by the RISC-V V intrinsics which require types of the form <vscale x 1 x i64>(LMUL=1 element size=64) or <vscale x 4 x i32>(LMUL=2 element size=32), etc. The vector_size attribute does not work for us as it doesn't create a scalable vector type. We want these types to be opaque and have no operators defined for them. We want them to be sizeless. This makes them similar to the ARM SVE builtin types. But we will have quite a bit more types. This patch adds around 60. Later patches will add another 230 or so types representing tuples of these types similar to the x2/x3/x4 types in ARM SVE. But with extra complexity that these types are combined with the LMUL concept that is unique to RISCV. For more background see this RFC http://lists.llvm.org/pipermail/llvm-dev/2020-October/145850.html Authored-by: Roger Ferrer Ibanez <roger.ferrer@bsc.es> Co-Authored-by: Hsiangkai Wang <kai.wang@sifive.com> Differential Revision: https://reviews.llvm.org/D92715
2021-02-03Fix the guaranteed alignment of memory returned by malloc/new on DarwinAkira Hatanaka1-1/+4
The guaranteed alignment is 16 bytes on Darwin. rdar://73431623 Differential Revision: https://reviews.llvm.org/D95910
2020-11-16[AMDGPU] Add option -munsafe-fp-atomicsYaxun (Sam) Liu1-0/+1
Add an option -munsafe-fp-atomics for AMDGPU target. When enabled, clang adds function attribute "amdgpu-unsafe-fp-atomics" to any functions for amdgpu target. This allows amdgpu backend to use unsafe fp atomic instructions in these functions. Differential Revision: https://reviews.llvm.org/D91546
2020-07-10Reland "[FPEnv][Clang][Driver] Disable constrained floating point on targets ↵Kevin P. Neal1-0/+1
lacking support." We currently have strict floating point/constrained floating point enabled for all targets. Constrained SDAG nodes get converted to the regular ones before reaching the target layer. In theory this should be fine. However, the changes are exposed to users through multiple clang options already in use in the field, and the changes are _completely_ _untested_ on almost all of our targets. Bugs have already been found, like "https://bugs.llvm.org/show_bug.cgi?id=45274". This patch disables constrained floating point options in clang everywhere except X86 and SystemZ. A warning will be printed when this happens. Use the new -fexperimental-strict-floating-point flag to force allowing strict floating point on hosts that aren't already marked as supporting it (X86 and SystemZ). Differential Revision: https://reviews.llvm.org/D80952
2020-07-06Revert "[FPEnv][Clang][Driver] Disable constrained floating point on targets ↵Kevin P. Neal1-1/+0
lacking support." My mistake, I had a blocking reviewer. This reverts commit 39d2ae0afb2312a15e4d15a0855b35b4e1c49fc4. This reverts commit bfdafa32a0fa4b2745627fe57dd253db10ac3fcf. This reverts commit 2b35511350454dd22997f129ee529e3fdb129ac2. Differential Revision: https://reviews.llvm.org/D80952
2020-07-06[FPEnv][Clang][Driver] Disable constrained floating point on targets lacking ↵Kevin P. Neal1-0/+1
support. We currently have strict floating point/constrained floating point enabled for all targets. Constrained SDAG nodes get converted to the regular ones before reaching the target layer. In theory this should be fine. However, the changes are exposed to users through multiple clang options already in use in the field, and the changes are _completely_ _untested_ on almost all of our targets. Bugs have already been found, like "https://bugs.llvm.org/show_bug.cgi?id=45274". This patch disables constrained floating point options in clang everywhere except X86 and SystemZ. A warning will be printed when this happens. Differential Revision: https://reviews.llvm.org/D80952
2020-06-05[ARM] Add __bf16 as new Bfloat16 C TypeTies Stuij1-0/+1
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-05-28[Clang] Enable KF and KC mode for [_Complex] __float128Nemanja Ivanovic1-1/+6
The headers provided with recent GNU toolchains for PPC have code that includes typedefs such as: typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__KC__))) This patch allows clang to compile programs that contain #include <math.h> with -mfloat128 which it currently fails to compile. Fixes: https://bugs.llvm.org/show_bug.cgi?id=46068 Differential revision: https://reviews.llvm.org/D80374
2020-03-28[AMDGPU] Add __builtin_amdgcn_workgroup_size_x/y/zYaxun (Sam) Liu1-0/+2
The main purpose of introducing these builtins is to add a range metadata [1, 1025) on the work group size loaded from dispatch ptr, which cannot be done by source code. Differential Revision: https://reviews.llvm.org/D76772
2020-03-17[AVR] Add support for the -mdouble=x flagAyke van Laethem1-0/+14
This flag is used by avr-gcc (starting with v10) to set the width of the double type. The double type is by default interpreted as a 32-bit floating point number in avr-gcc instead of a 64-bit floating point number as is common on other architectures. Starting with GCC 10, a new option has been added to control this behavior: https://gcc.gnu.org/wiki/avr-gcc#Deviations_from_the_Standard This commit keeps the default double at 32 bits but adds support for the -mdouble flag (-mdouble=32 and -mdouble=64) to control this behavior. Differential Revision: https://reviews.llvm.org/D76181
2020-03-09[ARM,CDE] Implement CDE feature test macrosMikhail Maltsev1-0/+1
Summary: This patch implements feature test macros for the CDE extension according to the upcoming ACLE specification. The following 2 macros are being added: - __ARM_FEATURE_CDE - defined as '1' when any coprocessor is configured as a CDE coprocessor - __ARM_FEATURE_CDE_COPROC - defined as an 8-bit mask, each bit of the mask corresponds to a coprocessor and is set when the corresponding coprocessor is configured as CDE (and cleared otherwise). The patch also exposes the value of __ARM_FEATURE_CDE_COPROC in the target-independent method TargetInfo::getARMCDECorpocMask, the method will be used in follow-up patches implementing semantic checks of CDE intrinsics (we want to diagnose the cases when CDE intrinsics are used with coprocessors that are not configured as CDE). Reviewers: simon_tatham, dmgreen, ostannard, MarkMurrayARM Reviewed By: simon_tatham Subscribers: kristof.beyls, danielkiss, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D75843
2019-10-21Prune include of DataLayout.h from include/clang/Basic/TargetInfo.h. NFCBjorn Pettersson1-0/+5
Summary: Use a forward declaration of DataLayout instead of including DataLayout.h in clangs TargetInfo.h. This reduces include dependencies toward DataLayout.h (and other headers such as DerivedTypes.h, Type.h that is included by DataLayout.h). Needed to move implemantation of TargetInfo::resetDataLayout from TargetInfo.h to TargetInfo.cpp. Reviewers: rnk Reviewed By: rnk Subscribers: jvesely, nhaehnle, cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69262 llvm-svn: 375438
2019-08-09Add SVE opaque built-in typesRichard Sandiford1-0/+1
This patch adds the SVE built-in types defined by the Procedure Call Standard for the Arm Architecture: https://developer.arm.com/docs/100986/0000 It handles the types in all relevant places that deal with built-in types. At the moment, some of these places bail out with an error, including: (1) trying to generate LLVM IR for the types (2) trying to generate debug info for the types (3) trying to mangle the types using the Microsoft C++ ABI (4) trying to @encode the types in Objective C (1) and (2) are fixed by follow-on patches but (unlike this patch) they deal mostly with target-specific LLVM details, so seemed like a logically separate change. There is currently no spec for (3) and (4), so reporting an error seems like the correct behaviour for now. The intention is that the types will become sizeless types: http://lists.llvm.org/pipermail/cfe-dev/2019-June/062523.html The main purpose of the sizeless type extension is to diagnose impossible or dangerous uses of the types, such as any that would require sizeof to have a meaningful defined value. Until then, the patch sets the alignments of the types to the values specified in the link above. It also sets the sizes of the types to zero, which is chosen to be consistently wrong and shouldn't affect correctly-written code (i.e. code that would compile even with the sizeless type extension). The patch adds the common subset of functionality needed to test the sizeless type extension on the one hand and to provide SVE intrinsic functions on the other. After this patch, the two pieces of work are essentially independent. The patch is based on one by Graham Hunter: https://reviews.llvm.org/D59245 Differential Revision: https://reviews.llvm.org/D62960 llvm-svn: 368413
2019-07-12[X86][PowerPC] Support -mlong-double-128Fangrui Song1-4/+9
This patch makes the driver option -mlong-double-128 available for X86 and PowerPC. The CC1 option -mlong-double-128 is available on all targets for users to test on unsupported targets. On PowerPC, -mlong-double-128 uses the IBM extended double format because we don't support -mabi=ieeelongdouble yet (D64283). Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D64277 llvm-svn: 365866
2019-07-09[X86][PPC] Support -mlong-double-64Fangrui Song1-0/+6
-mlong-double-64 is supported on some ports of gcc (i386, x86_64, and ppc{32,64}). On many other targets, there will be an error: error: unrecognized command line option '-mlong-double-64' This patch makes the driver option -mlong-double-64 available for x86 and ppc. The CC1 option -mlong-double-64 is available on all targets for users to test on unsupported targets. LongDoubleSize is added as a VALUE_LANGOPT so that the option can be shared with -mlong-double-128 when we support it in clang. Also, make powerpc*-linux-musl default to use 64-bit long double. It is currently the only supported ABI on musl and is also how people configure powerpc*-linux-musl-gcc. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D64067 llvm-svn: 365412
2019-02-10Use llvm::is_contained. NFCFangrui Song1-1/+1
llvm-svn: 353635
2019-01-30[HIP] Fix size_t for MSVC environmentYaxun Liu1-0/+6
In 64 bit MSVC environment size_t is defined as unsigned long long. In single source language like HIP, data layout should be consistent in device and host compilation, therefore copy data layout controlling fields from Aux target for AMDGPU target. Differential Revision: https://reviews.llvm.org/D56318 llvm-svn: 352620
2019-01-25Disable _Float16 for non ARM/SPIR TargetsErich Keane1-0/+1
As Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129543.html There are problems exposing the _Float16 type on architectures that haven't defined the ABI/ISel for the type yet, so we're temporarily disabling the type and making it opt-in. Differential Revision: https://reviews.llvm.org/D57188 Change-Id: I5db7366dedf1deb9485adb8948b1deb7e612a736 llvm-svn: 352221
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
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
2018-12-18Emit ASM input in a constant contextBill Wendling1-0/+2
Summary: Some ASM input constraints (e.g., "i" and "n") require immediate values. At O0, very few code transformations are performed. So if we cannot resolve to an immediate when emitting the ASM input we shouldn't delay its processing. Reviewers: rsmith, efriedma Reviewed By: efriedma Subscribers: rehana, efriedma, craig.topper, jyknight, cfe-commits Differential Revision: https://reviews.llvm.org/D55616 llvm-svn: 349561
generated by cgit v1.1 at 2025-10-01 09:38:20 +0000