summaryrefslogtreecommitdiffstats
path: root/clang/lib/Basic
Commit message (Collapse)AuthorAgeFilesLines
...
* Change std::{lower,upper}_bound to llvm::{lower,upper}_bound or ↵Fangrui Song2019-07-033-12/+8
| | | | | | llvm::partition_point. NFC llvm-svn: 365006
* Fix build failure due to missing breakYaxun Liu2019-06-261-0/+2
| | | | llvm-svn: 364380
* [ARM] Support inline assembler constraints for MVE.Simon Tatham2019-06-251-0/+11
| | | | | | | | | | | | | | | | | | | | | "To" selects an odd-numbered GPR, and "Te" an even one. There are some 8.1-M instructions that have one too few bits in their register fields and require registers of particular parity, without necessarily using a consecutive even/odd pair. Also, the constraint letter "t" should select an MVE q-register, when MVE is present. This didn't need any source changes, but some extra tests have been added. Reviewers: dmgreen, samparker, SjoerdMeijer Subscribers: javed.absar, eraman, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D60709 llvm-svn: 364331
* AMDGPU: Fix target builtins for gfx10Matt Arsenault2019-06-221-0/+2
| | | | | | This wasn't setting some of the features from older generations. llvm-svn: 364123
* PR42301: Abort cleanly if we encounter a huge source file rather thanRichard Smith2019-06-211-0/+25
| | | | | | | | | | crashing. Ideally we wouldn't care about the size of a file so long as it fits in memory, but in practice we have lots of hardocded assumptions that unsigned can be used to index files, string literals, and so on. llvm-svn: 364103
* [RISCV] Mark TLS as supportedLewis Revill2019-06-191-1/+0
| | | | | | | | Inform Clang that TLS is implemented by LLVM for RISC-V Differential Revision: https://reviews.llvm.org/D57055 llvm-svn: 363776
* Clang :: Sema/wchar.c has long been failing on Solaris:Rainer Orth2019-06-171-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | error: 'error' diagnostics expected but not seen: File /vol/llvm/src/clang/local/test/Sema/wchar.c Line 22: initializing wide char array with non-wide string literal error: 'error' diagnostics seen but not expected: File /vol/llvm/src/clang/local/test/Sema/wchar.c Line 20: array initializer must be an initializer list File /vol/llvm/src/clang/local/test/Sema/wchar.c Line 22: array initializer must be an initializer list It turns out the definition is wrong, as can be seen in GCC's gcc/config/sol2.h: /* wchar_t is called differently in <wchar.h> for 32 and 64-bit compilations. This is called for by SCD 2.4.1, p. 6-83, Figure 6-65 (32-bit) and p. 6P-10, Figure 6.38 (64-bit). */ #undef WCHAR_TYPE #define WCHAR_TYPE (TARGET_64BIT ? "int" : "long int") The following patch implements this, and at the same time corrects the wint_t definition which is the same: /* Same for wint_t. See SCD 2.4.1, p. 6-83, Figure 6-66 (32-bit). There's no corresponding 64-bit definition, but this is what Solaris 8 <iso/wchar_iso.h> uses. */ #undef WINT_TYPE #define WINT_TYPE (TARGET_64BIT ? "int" : "long int") Clang :: Preprocessor/wchar_t.c and Clang :: Sema/format-strings.c need to be adjusted to account for that. Tested on i386-pc-solaris2.11, x86_64-pc-solaris2.11, and x86_64-pc-linux-gnu. Differential Revision: https://reviews.llvm.org/D62944 llvm-svn: 363612
* [Targets] Move soft-float-abi filtering to `initFeatureMap`George Burgess IV2019-06-142-14/+25
| | | | | | | | | | | | | | | | | | ARM has a special target feature called soft-float-abi. This feature is special, since we get it passed to us explicitly in the frontend, but filter it out before it can land in any target feature strings in LLVM IR. __attribute__((target(""))) doesn't quite filter these features out properly, so today, we get warnings about soft-float-abi being an unknown feature from the backend. This CL has us filter soft-float-abi out at a slightly different point, so we don't end up passing these invalid features to the backend. Differential Revision: https://reviews.llvm.org/D61750 llvm-svn: 363346
* [AMDGPU] gfx1011/gfx1012 clang supportStanislav Mekhanoshin2019-06-141-0/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D63308 llvm-svn: 363345
* [RISCV] Add inline asm constraints I, J & K for RISC-VLewis Revill2019-06-112-3/+21
| | | | | | | | | | | | | | | | This allows the constraints I, J & K to be used in inline asm for RISC-V, with the following semantics (equivalent to GCC): I: Any 12-bit signed immediate. J: Integer zero only. K: Any 5-bit unsigned immediate. See the GCC definitions here: https://gcc.gnu.org/onlinedocs/gccint/Machine-Constraints.html Differential Revision: https://reviews.llvm.org/D54091 llvm-svn: 363055
* [X86] Attempt to make the Intel core CPU inheritance a little more readable ↵Craig Topper2019-06-101-24/+27
| | | | | | | | | | | | and maintainable The recently added cooperlake CPU has made our already ugly switch statement even worse. There's a CPU exclusion list around the bf16 feature in the cooper lake block. I worry that we'll have to keep adding new CPUs to that until bf16 intercepts a client space CPU. We have several other exclusion lists in other parts of the switch due to skylakeserver, cascadelake, and cooperlake not having sgx. Another for cannonlake not having clwb but having all other features from skx. This removes all these special ifs at the cost of some duplication of features and a goto. I've copied all of the skx features into either cannonlake or icelakeclient(for clwb). And pulled sklyakeserver, cascadelake, and cooperlake out of the main inheritance chain into their own chain. At the end of skylakeserver we merge back into the main chain at skylakeclient but below sgx. I think this is at least easier to follow. Differential Revision: https://reviews.llvm.org/D63018 llvm-svn: 362965
* [ARM] Add ACLE feature macros for MVE.David Green2019-06-071-0/+1
| | | | | | Fixup uninitialised variable. llvm-svn: 362814
* [ARM] Add ACLE feature macros for MVESjoerd Meijer2019-06-072-0/+30
| | | | | | | | | | | | | | | If MVE is present at all, then the macro __ARM_FEATURE_MVE is defined to a value which has bit 0 set for integer MVE, and bit 1 set for floating-point MVE. (Floating-point MVE implies integer MVE, so if this macro is defined at all then it will be set to 1 or 3, never 2.) Patch mostly by Simon Tatham Differential Revision: https://reviews.llvm.org/D60710 llvm-svn: 362806
* [ARM] Fix bugs introduced by the fp64/d32 rework.Simon Tatham2019-06-071-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change D60691 caused some knock-on failures that weren't caught by the existing tests. Firstly, selecting a CPU that should have had a restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs and no double precision) could give the unrestricted version, because `ARM::getFPUFeatures` returned a list of features including subtracted ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw away all the ones that didn't start with `+`. Secondly, the preprocessor macros didn't reliably match the actual compilation settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as if hardware FP was available, because the list of features on the cc1 command line would include things like `+vfp4`,`-vfp4d16` and clang didn't realise that one of those cancelled out the other. I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so that it returns a list that enables every FP-related feature compatible with the selected FPU and disables every feature not compatible, which is more verbose but means clang doesn't have to understand the dependency relationships between the backend features. Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all the various forms of the FP feature names, so that it won't miss cases where it should have set `HW_FP` to feed into feature test macros. That in turn caused an ordering problem when handling `-mcpu=foo+bar` together with `-mfpu=something_that_turns_off_bar`. To fix that, I've arranged that the `+bar` suffixes on the end of `-mcpu` and `-march` cause feature names to be put into a separate vector which is concatenated after the output of `getFPUFeatures`. Another side effect of all this is to fix a bug where `clang -target armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was because `HW_FP` was being set to a value including only the `FPARMV8` bit, but that feature test macro was testing only the `VFP4FPU` bit. Now `HW_FP` ends up with all the bits set, so it gives the right answer. Changes to tests included in this patch: * `arm-target-features.c`: I had to change basically all the expected results. (The Cortex-M4 test in there should function as a regression test for the accidental double-precision bug.) * `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG` everywhere so that those tests are no longer sensitive to the order of cc1 feature options on the command line. * `arm-acle-6.5.c`: been updated to expect the right answer to that FMA test. * `Preprocessor/arm-target-features.c`: added a regression test for the `mfpu=softvfp` issue. Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne Reviewed By: ostannard Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62998 llvm-svn: 362791
* [X86] -march=cooperlake (clang)Pengfei Wang2019-06-071-3/+11
| | | | | | | | | | Support intel -march=cooperlake in clang Patch by Shengchen Kan (skan) Differential Revision: https://reviews.llvm.org/D62835 llvm-svn: 362781
* [X86] Add ENQCMD instructionsPengfei Wang2019-06-062-0/+7
| | | | | | | | | | | | For more details about these instructions, please refer to the latest ISE document: https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-programming-reference. Patch by Tianqing Wang (tianqing) Differential Revision: https://reviews.llvm.org/D62282 llvm-svn: 362685
* [X86] Add VP2INTERSECT instructionsPengfei Wang2019-05-312-1/+8
| | | | | | | | | | Support intel AVX512 VP2INTERSECT instructions in clang Patch by Xiang Zhang (xiangzhangllvm) Differential Revision: https://reviews.llvm.org/D62367 llvm-svn: 362196
* [ARM] Add CLI support for Armv8.1-M and MVESjoerd Meijer2019-05-301-0/+2
| | | | | | | | | | | | Given the existing infrastructure in LLVM side for +fp and +fp.dp, this is more or less trivial, needing only one tiny source change and a couple of tests. Patch by Simon Tatham. Differential Revision: https://reviews.llvm.org/D60699 llvm-svn: 362096
* [ARM] Replace fp-only-sp and d16 with fp64 and d32.Simon Tatham2019-05-281-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Those two subtarget features were awkward because their semantics are reversed: each one indicates the _lack_ of support for something in the architecture, rather than the presence. As a consequence, you don't get the behavior you want if you combine two sets of feature bits. Each SubtargetFeature for an FP architecture version now comes in four versions, one for each combination of those options. So you can still say (for example) '+vfp2' in a feature string and it will mean what it's always meant, but there's a new string '+vfp2d16sp' meaning the version without those extra options. A lot of this change is just mechanically replacing positive checks for the old features with negative checks for the new ones. But one more interesting change is that I've rearranged getFPUFeatures() so that the main FPU feature is appended to the output list *before* rather than after the features derived from the Restriction field, so that -fp64 and -d32 can override defaults added by the main feature. Reviewers: dmgreen, samparker, SjoerdMeijer Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D60691 llvm-svn: 361845
* [X86] Split multi-line chained assignments into single lines to avoid making ↵Craig Topper2019-05-231-26/+24
| | | | | | | | clang-format create triangle shaped indentation. Simplify one if statement to remove a bunch of string matches. NFCI We had an if statement that checked over every avx512* feature to see if it should enabled avx512f. Since they are all prefixed with avx512 just check for that instead. llvm-svn: 361557
* [WebAssembly] Add multivalue and tail-call target featuresThomas Lively2019-05-232-0/+28
| | | | | | | | | | | | | | | | Summary: These features will both be implemented soon, so I thought I would save time by adding the boilerplate for both of them at the same time. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62047 llvm-svn: 361516
* [OpenCL] Support pipe keyword in C++ modeSven van Haastregt2019-05-221-2/+3
| | | | | | | | | | | | Support the OpenCL C pipe feature in C++ for OpenCL mode, to preserve backwards compatibility with OpenCL C. Various changes had to be made in Parse and Sema to enable pipe-specific diagnostics, so enable a SemaOpenCL test for C++. Differential Revision: https://reviews.llvm.org/D62181 llvm-svn: 361382
* [PPC64] Fix PPC64TargetInfo ABI on clang side after D61950Fangrui Song2019-05-221-1/+2
| | | | llvm-svn: 361365
* [PPC64] Fix PPC64TargetInfo after D61950Fangrui Song2019-05-221-0/+1
| | | | llvm-svn: 361363
* [PPC64] Parse -elfv1 -elfv2 when specified on target tripleFangrui Song2019-05-221-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: For big-endian powerpc64, the default ABI is ELFv1. OpenPower ABI ELFv2 is supported when -mabi=elfv2 is specified. FreeBSD support for PowerPC64 ELFv2 ABI with LLVM is in progress[1]. This patch adds an alternative way to specify ELFv2 ABI on target triple [2]. The following results are expected: ELFv1 when using: -target powerpc64-unknown-freebsd12.0 -target powerpc64-unknown-freebsd12.0 -mabi=elfv1 -target powerpc64-unknown-freebsd12.0-elfv1 ELFv2 when using: -target powerpc64-unknown-freebsd12.0 -mabi=elfv2 -target powerpc64-unknown-freebsd12.0-elfv2 [1] https://wiki.freebsd.org/powerpc/llvm-elfv2 [2] https://clang.llvm.org/docs/CrossCompilation.html Patch by Alfredo Dal'Ava Júnior! Differential Revision: https://reviews.llvm.org/D61950 llvm-svn: 361355
* [DebugInfo] Don't emit checksums when compiling a preprocessed CPPAlexandre Ganea2019-05-211-2/+7
| | | | | | | | Fixes PR41215 Differential Revision: https://reviews.llvm.org/D60283 llvm-svn: 361296
* [ARM][CMSE] Add commandline option and feature macroJaved Absar2019-05-211-0/+9
| | | | | | | | | | | Defines macro ARM_FEATURE_CMSE to 1 for v8-M targets and introduces -mcmse option which for v8-M targets sets ARM_FEATURE_CMSE to 3. A diagnostic is produced when the option is given on architectures without support for Security Extensions. Reviewed By: dmgreen, snidertm Differential Revision: https://reviews.llvm.org/D59879 llvm-svn: 361261
* [X86] Stop implicitly enabling avx512vl when avx512bf16 is enabled.Craig Topper2019-05-161-3/+1
| | | | | | | | Previously we were doing this so that the 256 bit selectw builtin could be used in the implementation of the 512->256 bit conversion intrinsic. After this commit we now use a masked convert builtin that will emit the intrinsic call and the 256-bit select from custom code in CGBuiltin. Then the header only needs to call that one intrinsic. llvm-svn: 360924
* Add AIX Version MacrosXing Xue2019-05-161-1/+17
| | | | | | | | | | | | | | | | | | | | Summary: - This patch checks the AIX version and defines the appropriate macros. - Follow up to a comment on D59048. Author: andusy Reviewers: hubert.reinterpretcast, jasonliu, sfertile, xingxue Reviewed By: sfertile Subscribers: jsji, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61530 llvm-svn: 360900
* [AMDGPU] gfx1010 clang targetStanislav Mekhanoshin2019-05-132-1/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D61875 llvm-svn: 360634
* [Preamble] Stop circular inclusion of main file when building preambleNikolai Kosjar2019-05-101-1/+1
| | | | | | | | | | | | | | | If a header file was processed for the second time, we could end up with a wrong conditional stack and skipped ranges: In the particular example, if the header guard is evaluated the second time and it is decided to skip the conditional block, the corresponding "#endif" is never seen since the preamble does not include it and we end up in the Tok.is(tok::eof) case with a wrong conditional stack. Detect the circular inclusion, emit a diagnostic and stop processing the inclusion. llvm-svn: 360418
* Assume `__cxa_allocate_exception` returns an under-aligned memory onAkira Hatanaka2019-05-101-0/+31
| | | | | | | | | | | | | | | | | | | | | Darwin if the version of libc++abi isn't new enough to include the fix in r319123 This patch resurrects r264998, which was committed to work around a bug in libc++abi that was causing _cxa_allocate_exception to return a memory that wasn't double-word aligned. http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160328/154332.html In addition, this patch makes clang issue a warning if the type of the thrown object requires an alignment that is larger than the minimum guaranteed by the target C++ runtime. rdar://problem/49864414 Differential Revision: https://reviews.llvm.org/D61667 llvm-svn: 360404
* [clang] Fix a bug that reports UTF32 (LE) files as UTF16 (LE) onesOwen Pan2019-05-081-3/+3
| | | | | | | | Also fix a typo for the SCSU byte order mark. Differential Revision: https://reviews.llvm.org/D61628 llvm-svn: 360256
* -frewrite-imports: Add support for wildcard rules in umbrella modules withDavid Blaikie2019-05-071-0/+15
| | | | | | | | | | This trips over a few other limitations, but in the interests of incremental development I'm starting here & I'll look at the issues with -verify and filesystem checks (the fact that the behavior depends on the existence of a 'foo' directory even though it shouldn't need it), etc. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D61656 llvm-svn: 360195
* Fix typo in risc-v register aliases.Eric Christopher2019-05-071-1/+1
| | | | | | | | Patch by John. Differential Revision: https://reviews.llvm.org/D61464 llvm-svn: 360104
* Enable intrinsics of AVX512_BF16, which are supported for BFLOAT16 in Cooper ↵Luo, Yuanke2019-05-062-0/+14
| | | | | | | | | | | | | | | | | | | | | | | Lake Summary: 1. Enable infrastructure of AVX512_BF16, which is supported for BFLOAT16 in Cooper Lake; 2. Enable intrinsics for VCVTNE2PS2BF16, VCVTNEPS2BF16 and DPBF16PS instructions, which are Vector Neural Network Instructions supporting BFLOAT16 inputs and conversion instructions from IEEE single precision. For more details about BF16 intrinsic, please refer to the latest ISE document: https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-programming-reference Patch by LiuTianle Reviewers: craig.topper, smaslov, LuoYuanke, wxiao3, annita.zhang, spatel, RKSimon Reviewed By: craig.topper Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60552 llvm-svn: 360018
* [COFF, ARM64] Align global symbol by size for ARM64 MSVC ABITom Tan2019-05-023-1/+20
| | | | | | | | | | | | | | | | | According to alignment section in below ARM64 ABI document, MSVC could increase alignment of global data based on its total size. Clang doesn't do this. Compile the same symbol into different alignments by Clang and MSVC could cause link error because some instruction encodings, like 64-bit LDR/STR with immediate, require the target to be 8 bytes aligned, and linker could choose code stream with such LDR/STR instruction from MSVC and 4 bytes aligned data from Clang into final image, which actually cannot be linked together (see https://bugs.llvm.org/show_bug.cgi?id=41506 for more details). https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#alignment Differential Revision: https://reviews.llvm.org/D61225 llvm-svn: 359744
* AMDGPU: Enable _Float16Yaxun Liu2019-04-301-0/+3
| | | | llvm-svn: 359594
* [AArch64] Initialize HasMTEVitaly Buka2019-04-271-0/+1
| | | | llvm-svn: 359366
* [AArch64] Add support for MTE intrinsicsJaved Absar2019-04-262-0/+6
| | | | | | | | | | | | This provides intrinsics support for Memory Tagging Extension (MTE), which was introduced with the Armv8.5-a architecture. These intrinsics are available when __ARM_FEATURE_MEMORY_TAGGING is defined. Each intrinsic is described in detail in the ACLE Q1 2019 documentation: https://developer.arm.com/docs/101028/latest Reviewed By: Tim Nortover, David Spickett Differential Revision: https://reviews.llvm.org/D60485 llvm-svn: 359348
* [BPF] do not generate predefined macro bpfYonghong Song2019-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | "DefineStd(Builder, "bpf", Opts)" generates the following three macros: bpf __bpf __bpf__ and the macro "bpf" is due to the fact that the target language is C which allows GNU extensions. The name "bpf" could be easily used as variable name or type field name. For example, in current linux kernel, there are four places where bpf is used as a field name. If the corresponding types are included in bpf program, the compilation error will occur. This patch removed predefined macro "bpf" as well as "__bpf" which is rarely used if used at all. Signed-off-by: Yonghong Song <yhs@fb.com> Differential Revision: https://reviews.llvm.org/D61173 llvm-svn: 359310
* [CUDA] Implemented _[bi]mma* builtins.Artem Belevich2019-04-251-0/+2
| | | | | | | | | | | | | | | | These builtins provide access to the new integer and sub-integer variants of MMA (matrix multiply-accumulate) instructions provided by CUDA-10.x on sm_75 (AKA Turing) GPUs. Also added a feature for PTX 6.4. While Clang/LLVM does not generate any PTX instructions that need it, we still need to pass it through to ptxas in order to be able to compile code that uses the new 'mma' instruction as inline assembly (e.g used by NVIDIA's CUTLASS library https://github.com/NVIDIA/cutlass/blob/master/cutlass/arch/mma.h#L101) Differential Revision: https://reviews.llvm.org/D60279 llvm-svn: 359248
* [Builtins] Implement __builtin_is_constant_evaluated for use in C++2aEric Fiselier2019-04-241-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements `__builtin_is_constant_evaluated` as specifier by [P0595R2](https://wg21.link/p0595r2). It is built on the back of Bill Wendling's work for `__builtin_constant_p()`. More tests to come, but early feedback is appreciated. I plan to implement warnings for common mis-usages like those belowe in a following patch: ``` void foo(int x) { if constexpr (std::is_constant_evaluated())) { // condition is always `true`. Should use plain `if` instead. foo_constexpr(x); } else { foo_runtime(x); } } ``` Reviewers: rsmith, MaskRay, bruno, void Reviewed By: rsmith Subscribers: dexonsmith, zoecarver, fdeazeve, kristina, cfe-commits Differential Revision: https://reviews.llvm.org/D55500 llvm-svn: 359067
* [FileSystemStatCache] Return std::error_code from stat cache methodsHarlan Haskins2019-04-162-23/+25
| | | | | | | | | | | | | | | | | | | | | | Summary: Previously, we would return true/false signifying if the cache/lookup succeeded or failed. Instead, provide clients with the underlying error that was thrown while attempting to look up in the cache. Since clang::FileManager doesn't make use of this information, it discards the error that's received and casts away to bool. This change is NFC. Reviewers: benlangmuir, arphaman Subscribers: dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60735 llvm-svn: 358509
* [C++20] Implement context-sensitive header-name lexing and pp-import parsing ↵Richard Smith2019-04-111-1/+1
| | | | | | in the preprocessor. llvm-svn: 358231
* [AMDGPU] rename vi-insts into gfx8-instsStanislav Mekhanoshin2019-04-051-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D60293 llvm-svn: 357792
* Make SourceManager::createFileID(UnownedTag, ...) take a const ↵Nico Weber2019-04-041-15/+17
| | | | | | | | | | | | | | | | | | | | | llvm::MemoryBuffer* Requires making the llvm::MemoryBuffer* stored by SourceManager const, which in turn requires making the accessors for that return const llvm::MemoryBuffer*s and updating all call sites. The original motivation for this was to use it and fix the TODO in CodeGenAction.cpp's ConvertBackendLocation() by using the UnownedTag version of createFileID, and since llvm::SourceMgr* hands out a const llvm::MemoryBuffer* this is required. I'm not sure if fixing the TODO this way actually works, but this seems like a good change on its own anyways. No intended behavior change. Differential Revision: https://reviews.llvm.org/D60247 llvm-svn: 357724
* [WebAssembly] Add Emscripten OS definition + small_printfAlon Zakai2019-04-032-0/+19
| | | | | | | | | | | | | | | The Emscripten OS provides a definition of __EMSCRIPTEN__, and also that it supports iprintf optimizations. Also define small_printf optimizations, which is a printf with float support but not long double (which in wasm can be useful since long doubles are 128 bit and force linking of float128 emulation code). This part is based on sunfish's https://reviews.llvm.org/D57620 (which can't land yet since the WASI integration isn't ready yet). Differential Revision: https://reviews.llvm.org/D60167 llvm-svn: 357552
* Fix Wimplicit-fallthrough warning introduced in rL357466. NFCI.Simon Pilgrim2019-04-021-0/+1
| | | | llvm-svn: 357467
* [PowerPC] Fix issue with inline asm - soft float modeStrahinja Petrovic2019-04-022-1/+12
| | | | | | | | | This patch prevents floating point register constraints in soft float mode. Differential Revision: https://reviews.llvm.org/D59310 llvm-svn: 357466
OpenPOWER on IntegriCloud