aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Basic/TargetInfo.cpp
AgeCommit message (Collapse)AuthorFilesLines
2017-06-26[inline asm][gcc-compatiblity] "=i" output constraint supportMarina Yatsina1-0/+5
Ignore ‘i’,’n’,’E’,’F’ as output constraints in inline assembly (gcc compatibility) Differential Revision: https://reviews.llvm.org/D31383 llvm-svn: 306297
2017-06-03Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova1-0/+2
llvm-svn: 304652
2017-03-22Move setting of LangOpts based on target flags out of CompilerInstanceEric Christopher1-2/+3
and into TargetInfo::adjust so that it gets called in more places throughout the compiler (AST serialization in particular). Should fix PPC modules after removing of faltivec. llvm-svn: 298487
2016-12-26[inline-asm]No error for conflict between inputs\outputs and clobber listMarina Yatsina1-3/+3
According to extended asm syntax, a case where the clobber list includes a variable from the inputs or outputs should be an error - conflict. for example: const long double a = 0.0; int main() { char b; double t1 = a; __asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st", "st(1)"); return 0; } This should conflict with the output - t1 which is st, and st which is st aswell. The patch fixes it. Commit on behald of Ziv Izhar. Differential Revision: https://reviews.llvm.org/D15075 llvm-svn: 290539
2016-12-14Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann1-12/+12
At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
2016-09-30P0035R4: add predefined __STDCPP_DEFAULT_NEW_ALIGNMENT__ macro. By default, weRichard Smith1-0/+10
assume that ::operator new provides no more alignment than is necessary for any primitive type, except when we're on a GNU OS, where glibc's malloc guarantees to provide 64-bit alignment on 32-bit systems and 128-bit alignment on 64-bit systems. This can be controlled by the command-line -fnew-alignment flag. llvm-svn: 282974
2016-09-07OpenCL: Defining __ENDIAN_LITTLE__ and fix target endiannessMatt Arsenault1-1/+1
OpenCL requires __ENDIAN_LITTLE__ be set for little endian targets. The default for targets was also apparently big endian, so AMDGPU was incorrectly reported as big endian. Set this from the triple so targets don't have another place to set the endianness. llvm-svn: 280787
2016-08-19Re-commit [OpenCL] AMDGCN: Fix size_t typeYaxun Liu1-2/+3
There was a premature cast to pointer type in emitPointerArithmetic which caused assertion in tests with assertion enabled. llvm-svn: 279206
2016-08-18Revert [OpenCL] AMDGCN: Fix size_t typeYaxun Liu1-3/+2
due to regressions in test/CodeGen/exprs.c on certain platforms. llvm-svn: 279127
2016-08-18[OpenCL] AMDGCN: Fix size_t typeYaxun Liu1-2/+3
Pointers of certain GPUs in AMDGCN target in private address space is 32 bit but pointers in other address spaces are 64 bit. size_t type should be defined as 64 bit for these GPUs so that it could hold pointers in all address spaces. Also fixed issues in pointer arithmetic codegen by using pointer specific intptr type. Differential Revision: https://reviews.llvm.org/D23361 llvm-svn: 279121
2016-07-27Adjust coercion of aggregates on RenderScriptPirama Arumuga Nainar1-0/+1
Summary: In RenderScript, the size of the argument or return value emitted in the IR is expected to be the same as the size of corresponding qualified type. For ARM and AArch64, the coercion performed by Clang can change the parameter or return value to a type whose size is different (usually larger) than the original aggregate type. Specifically, this can happen in the following cases: - Aggregate parameters of size <= 64 bytes and return values smaller than 4 bytes on ARM - Aggregate parameters and return values smaller than bytes on AArch64 This patch coerces the cases above to an integer array that is the same size and alignment as the original aggregate. A new field is added to TargetInfo to detect a RenderScript target and limit this coercion just to that case. Tests added to test/CodeGen/renderscript.c Reviewers: rsmith Subscribers: aemerson, srhines, llvm-commits Differential Revision: https://reviews.llvm.org/D22822 llvm-svn: 276904
2016-05-09Enable support for __float128 in Clang and enable it on pertinent platformsNemanja Ivanovic1-0/+5
This patch corresponds to reviews: http://reviews.llvm.org/D15120 http://reviews.llvm.org/D19125 It adds support for the __float128 keyword, literals and target feature to enable it. Based on the latter of the two aforementioned reviews, this feature is enabled on Linux on i386/X86 as well as SystemZ. This is also the second attempt in commiting this feature. The first attempt did not enable it on required platforms which caused failures when compiling type_traits with -std=gnu++11. If you see failures with compiling this header on your platform after this commit, it is likely that your platform needs to have this feature enabled. llvm-svn: 268898
2016-05-04[X86] Add -malign-double supportReid Kleckner1-0/+4
The -malign-double flag causes i64 and f64 types to have alignment 8 instead of 4. On x86-64, the behavior of -malign-double is enabled by default. Rebases and cleans phosek's work here: http://reviews.llvm.org/D12860 Patch by Sean Klein Reviewers: rnk Subscribers: rnk, jfb, dschuff, phosek Differential Revision: http://reviews.llvm.org/D19734 llvm-svn: 268473
2016-04-15Revert 266186 as it breaks anything that includes type_traits on some platformsNemanja Ivanovic1-4/+0
Since this patch provided support for the __float128 type but disabled it on all platforms by default, some platforms can't compile type_traits with -std=gnu++11 since there is a specialization with __float128. This reverts the patch until D19125 is approved (i.e. we know which platforms need this support enabled). llvm-svn: 266460
2016-04-13Enable support for __float128 in ClangNemanja Ivanovic1-0/+4
This patch corresponds to review: http://reviews.llvm.org/D15120 It adds support for the __float128 keyword, literals and a target feature to enable it. This support is disabled by default on all targets and any target that has support for this type is free to add it. Based on feedback that I've received from target maintainers, this appears to be the right thing for most targets. I have not heard from the maintainers of X86 which I believe supports this type. I will subsequently investigate the impact of enabling this on X86. llvm-svn: 266186
2016-03-04Make TargetInfo store an actual DataLayout instead of a string.James Y Knight1-2/+0
Use it to calculate UserLabelPrefix, instead of specifying it (often incorrectly). Note that the *actual* user label prefix has always come from the DataLayout, and is handled within LLVM. The main thing clang's TargetInfo::UserLabelPrefix did was to set the #define value. Having these be different from each-other is just silly. Differential Revision: http://reviews.llvm.org/D17183 llvm-svn: 262737
2016-02-05Do not honor explicit alignment attribute on fields for PS4.Sunil Srivastava1-0/+1
This change reverts r257462 for PS4 triple. Differential Revision: http://reviews.llvm.org/D16788 llvm-svn: 259916
2016-01-27Revert "Change of UserLabelPrefix default value from "_" to """James Y Knight1-1/+1
This reverts commit r258504. This commit breaks (at least) sparc-rtems -- the OS (RTEMS) used to override UserLabelPrefix to "", despite the arch (SPARC) having set it to "_". Now, the OS doesn't override anymore, but the arch sets it to "_", resulting in the wrong value. I expect this probably breaks other OSes that overrode to "" before, as well. (Clearly we have some missing test cases, here...) llvm-svn: 258894
2016-01-22Change of UserLabelPrefix default value from "_" to ""Andrey Bokhanko1-1/+1
Differential Revision: http://reviews.llvm.org/D16295 llvm-svn: 258504
2015-10-21Use StringRef instead of calling c_str and doing pointer math before ↵Craig Topper1-2/+2
eventually creating a StringRef. NFC llvm-svn: 250902
2015-10-21Use range-based for loops. NFC.Craig Topper1-24/+18
llvm-svn: 250881
2015-10-21Use std::find instead of a manual loop.Craig Topper1-4/+2
llvm-svn: 250880
2015-10-21Parse into an unsigned type instead of a signed type and then checking for ↵Craig Topper1-5/+4
positive and casting to unsigned. Since we know the string starts with a digit it couldn't be negative anyway. NFCI llvm-svn: 250879
2015-10-21Fix bad indentation.Craig Topper1-1/+1
llvm-svn: 250878
2015-10-21Use ArrayRef and MutableArrayRef instead of a pointer and size. NFCCraig Topper1-8/+7
llvm-svn: 250876
2015-10-20Roll-back r250822.Angel Garcia Gomez1-1/+1
Summary: It breaks the build for the ASTMatchers Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D13893 llvm-svn: 250827
2015-10-20Apply modernize-use-default to clang.Angel Garcia Gomez1-1/+1
Summary: Replace empty bodies of default constructors and destructors with '= default'. Reviewers: bkramer, klimek Subscribers: klimek, alexfh, cfe-commits Differential Revision: http://reviews.llvm.org/D13890 llvm-svn: 250822
2015-10-19Recommit "Return an ArrayRef instead of having two out parameters of a ↵Craig Topper1-31/+15
pointer and length. NFC". Hopefully this time the bots will be happy. llvm-svn: 250678
2015-10-19Revert r250676 "Return an ArrayRef instead of having two out parameters of a ↵Craig Topper1-15/+31
pointer and length. NFC" llvm-svn: 250677
2015-10-19Return an ArrayRef instead of having two out parameters of a pointer and ↵Craig Topper1-31/+15
length. NFC llvm-svn: 250676
2015-10-09Fix whitespace, 80-column violations, embedded tabs for theEric Christopher1-10/+10
TargetInfo class. llvm-svn: 249872
2015-10-09constify the feature vector going into initFeatureMap as it shouldn'tEric Christopher1-3/+3
change the set of features. llvm-svn: 249871
2015-09-17Support __builtin_ms_va_list.Charles Davis1-0/+1
Summary: This change adds support for `__builtin_ms_va_list`, a GCC extension for variadic `ms_abi` functions. The existing `__builtin_va_list` support is inadequate for this because `va_list` is defined differently in the Win64 ABI vs. the System V/AMD64 ABI. Depends on D1622. Reviewers: rsmith, rnk, rjmccall CC: cfe-commits Differential Revision: http://reviews.llvm.org/D1623 llvm-svn: 247941
2015-09-01Pull initFeatureMap out of line now that it's used in multiple places.Eric Christopher1-0/+12
llvm-svn: 246565
2015-08-31Revert "Pull the target attribute parsing out of CGCall and onto TargetInfo."Eric Christopher1-47/+0
This reverts commit r246468 while we figure out what to do about Basic and AST. llvm-svn: 246508
2015-08-31Pull the target attribute parsing out of CGCall and onto TargetInfo.Eric Christopher1-0/+47
Also: - Add a typedef to make working with the result easier. - Update callers to use the new function. - Make initFeatureMap out of line. llvm-svn: 246468
2015-08-26Remove dead code associated with parsing and setting ABI based onEric Christopher1-15/+0
string name. llvm-svn: 246021
2015-08-05Rename DescriptionString -> DataLayoutString as it matches the actualEric Christopher1-1/+1
use of the string. llvm-svn: 244178
2015-07-14Add a "maximum TLS alignment" characteristic to the target info, so itPaul Robinson1-0/+1
can be different from the normal variable maximum. Add an error diagnostic for when TLS variables exceed maximum TLS alignment. Currenty only PS4 sets an explicit maximum TLS alignment. Patch by Charles Li! llvm-svn: 242198
2015-07-02[OPENMP] Introduced type trait "__builtin_omp_required_simd_align" for ↵Alexey Bataev1-0/+1
default simd alignment. Adds type trait "__builtin_omp_required_simd_align" after discussions here http://reviews.llvm.org/D9894 Differential Revision: http://reviews.llvm.org/D10597 llvm-svn: 241237
2015-04-29Revert code changes made under r235976.Bradley Smith1-1/+0
This issue was fixed elsewhere in r235396 in a more general way, hence these changes no longer do anything. Keep the testcase however, to ensure that we don't regress this for ARM. llvm-svn: 236104
2015-04-28[ARM/AArch64] Enforce alignment for bitfielded structsBradley Smith1-0/+1
When creating a global variable with a type of a struct with bitfields, we must forcibly set the alignment of the global from the RecordDecl. We must do this so that the proper bitfield alignment makes its way down to LLVM, since clang will mangle the bitfields into one large type. llvm-svn: 235976
2015-04-21Implement target-specific __attribute__((aligned)) valueUlrich Weigand1-0/+1
The GCC construct __attribute__((aligned)) is defined to set alignment to "the default alignment for the target architecture" according to the GCC documentation: The default alignment is sufficient for all scalar types, but may not be enough for all vector types on a target that supports vector operations. The default alignment is fixed for a particular target ABI. clang currently hard-coded an alignment of 16 bytes for that construct, which is correct on some platforms (including X86), but wrong on others (including SystemZ). Since this value is ABI-relevant, it is important to get correct for compatibility purposes. This patch adds a new TargetInfo member "DefaultAlignForAttributeAligned" that targets can set to the appropriate default __attribute__((aligned)) value. Note that I'm deliberately *not* using the existing "SuitableAlign" value, which is used to set the pre-defined macro __BIGGEST_ALIGNMENT__, since those two values may not be the same on all platforms. In fact, on X86, __attribute__((aligned)) always uses 16-byte alignment, while __BIGGEST_ALIGNMENT__ may be larger if AVX-2 or AVX-512 are supported. (This is actually not yet correctly implemented in clang either.) The patch provides a value for DefaultAlignForAttributeAligned only for SystemZ, and leaves the default for all other targets at 16, which means no visible change in behavior on all other targets. (The value is still wrong for some other targets, but I'd prefer to leave it to the target maintainers for those platforms to fix.) llvm-svn: 235397
2015-02-23Fixed typo.Zoran Jovanovic1-1/+1
llvm-svn: 230253
2015-02-18Change representation of member function pointers for MIPS targetsZoran Jovanovic1-0/+1
Differential Revision: http://reviews.llvm.org/D7148 llvm-svn: 229680
2015-01-14Sema: Relax parsing of '#' in constraintsDavid Majnemer1-4/+0
llvm-svn: 225942
2015-01-11Basic: Numeric constraints are multidigitDavid Majnemer1-3/+9
Clang would treat the digits in an "11m" input constraint separately as if it was handling constraint 1 twice instead of constraint 11. llvm-svn: 225606
2015-01-11Basic: [asmSymbolicName] follows the same rule as numbers in asm inputsDavid Majnemer1-0/+4
Input constraints like "0" and "[foo]" should be treated the same when it comes to their corresponding output constraint. This fixes PR21850. llvm-svn: 225605
2015-01-11Basic: The asm constraint '#m' isn't valid, reject itDavid Majnemer1-1/+7
llvm-svn: 225603
2015-01-11Basic: The asm constraint '+#r' isn't valid, reject itDavid Majnemer1-1/+5
llvm-svn: 225600
generated by cgit v1.1 at 2025-10-12 10:46:11 +0000