summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* Fix some errors in <arm_neon.h> tests that cause them to fail with laxRichard Smith2019-10-102-10/+10
| | | | | | vector conversions disabled. llvm-svn: 374457
* [ARM] Fix arm_neon.h with -flax-vector-conversions=none, part 2.Eli Friedman2019-10-102-75/+76
| | | | | | | | | | | | | | | | | | | | | Just running -fsyntax-only over arm_neon.h doesn't cover some intrinsics which are defined using macros. Add more test coverage for that. arm-neon-header.c wasn't checking the full set of available NEON target features; change the target architecture of the test to account for that. Fix the generator for arm_neon.h to generate casts in more cases where they are necessary. Fix VFMLAL_LOW etc. to express their signatures differently, so the builtins have the expected type. Maybe the TableGen backend should detect intrinsics that are defined the wrong way, and produce an error. The rules here are sort of strange. Differential Revision: https://reviews.llvm.org/D68743 llvm-svn: 374419
* Update clang tests for new LLVM IR backslash printing in r374415Reid Kleckner2019-10-103-8/+8
| | | | llvm-svn: 374416
* Revert "[IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator"Dmitri Gribenko2019-10-1019-344/+344
| | | | | | | This reverts commit r374240. It broke OCaml tests: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/19014 llvm-svn: 374354
* [UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined ↵Roman Lebedev2019-10-108-193/+1027
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behaviour Summary: Quote from http://eel.is/c++draft/expr.add#4: ``` 4 When an expression J that has integral type is added to or subtracted from an expression P of pointer type, the result has the type of P. (4.1) If P evaluates to a null pointer value and J evaluates to 0, the result is a null pointer value. (4.2) Otherwise, if P points to an array element i of an array object x with n elements ([dcl.array]), the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) array element i+j of x if 0≤i+j≤n and the expression P - J points to the (possibly-hypothetical) array element i−j of x if 0≤i−j≤n. (4.3) Otherwise, the behavior is undefined. ``` Therefore, as per the standard, applying non-zero offset to `nullptr` (or making non-`nullptr` a `nullptr`, by subtracting pointer's integral value from the pointer itself) is undefined behavior. (*if* `nullptr` is not defined, i.e. e.g. `-fno-delete-null-pointer-checks` was *not* specified.) To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer is undefined, although Clang front-end pessimizes the code by not lowering that info, so this UB is "harmless". Since rL369789 (D66608 `[InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null`) LLVM middle-end uses those guarantees for transformations. If the source contains such UB's, said code may now be miscompiled. Such miscompilations were already observed: * https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html * https://github.com/google/filament/pull/1566 Surprisingly, UBSan does not catch those issues ... until now. This diff teaches UBSan about these UB's. `getelementpointer inbounds` is a pretty frequent instruction, so this does have a measurable impact on performance; I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%), and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark: (all measurements done with LLVM ToT, the sanitizer never fired.) * no sanitization vs. existing check: average `+21.62%` slowdown * existing check vs. check after this patch: average `22.04%` slowdown * no sanitization vs. this patch: average `48.42%` slowdown Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers Reviewed By: rsmith Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D67122 llvm-svn: 374293
* [IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperatorCameron McInally2019-10-0919-344/+344
| | | | | | | | Also update Clang to call Builder.CreateFNeg(...) for UnaryMinus. Differential Revision: https://reviews.llvm.org/D61675 llvm-svn: 374240
* [ARM] Fix arm_neon.h with -flax-vector-conversions=noneEli Friedman2019-10-0910-601/+196
| | | | | | | | | | | | | | Really, we were already 99% of the way there; just needed a couple minor fixes that affected 64-bit-only builtins. Based on D61717. Note that the change to builtin_str changes the type of a few __builtin_neon_* intrinsics that had the "wrong" type. Fixes https://bugs.llvm.org/show_bug.cgi?id=43341 Differential Revision: https://reviews.llvm.org/D68683 llvm-svn: 374191
* [WebAssembly] Add builtin and intrinsic for v8x16.swizzleThomas Lively2019-10-091-1/+6
| | | | | | | | | | | | | | | | | | | | | | Summary: This clang builtin and corresponding LLVM intrinsic are necessary to expose the exact semantics of the underlying WebAssembly instruction to users. LLVM produces a poison value if the dynamic swizzle indices are greater than the vector size, but the WebAssembly instruction sets the corresponding output lane to zero. Users who depend on this behavior can safely use this builtin. Depends on D68527. Reviewers: aheejin, dschuff Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68531 llvm-svn: 374189
* [DebugInfo] Enable call site debug info for ARM and AArch64Nikola Prica2019-10-091-0/+4
| | | | | | | | | | | | | | | | | ARM and AArch64 SelectionDAG support for tacking parameter forwarding register is implemented so we can allow clang invocations for those two targets. Beside that restrict debug entry value support to be emitted for LimitedDebugInfo info and FullDebugInfo. Other types of debug info do not have functions nor variables debug info. Reviewers: aprantl, probinson, dstenb, vsk Reviewed By: vsk Differential Revision: https://reviews.llvm.org/D67004 llvm-svn: 374153
* Revert r374006: Reland 'Add VFS support for sanitizers' blacklist'Ilya Biryukov2019-10-092-51/+0
| | | | | | | | | | | Also revert follow-up changes to the test. Reason: the patch breaks our internal clang-tidy integration. It's also unclear why we should use getRealPath instead of plumbing the VFS to SanitizerBlacklist, see original commit thread of cfe-commits for a discussion. llvm-svn: 374151
* [IRGen] Emit lifetime markers for temporary struct allocasFrancis Visoiu Mistrih2019-10-081-0/+89
| | | | | | | | | | | | | | When passing arguments using temporary allocas, we need to add the appropriate lifetime markers so that the stack coloring passes can re-use the stack space. This patch keeps track of all the lifetime.start calls emited before the codegened call, and adds the corresponding lifetime.end calls after the call. Differential Revision: https://reviews.llvm.org/D68611 llvm-svn: 374126
* Try to get ubsan-blacklist-vfs.c pass more on WindowsNico Weber2019-10-081-2/+2
| | | | llvm-svn: 374105
* [BPF] do compile-once run-everywhere relocation for bitfieldsYonghong Song2019-10-082-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A bpf specific clang intrinsic is introduced: u32 __builtin_preserve_field_info(member_access, info_kind) Depending on info_kind, different information will be returned to the program. A relocation is also recorded for this builtin so that bpf loader can patch the instruction on the target host. This clang intrinsic is used to get certain information to facilitate struct/union member relocations. The offset relocation is extended by 4 bytes to include relocation kind. Currently supported relocation kinds are enum { FIELD_BYTE_OFFSET = 0, FIELD_BYTE_SIZE, FIELD_EXISTENCE, FIELD_SIGNEDNESS, FIELD_LSHIFT_U64, FIELD_RSHIFT_U64, }; for __builtin_preserve_field_info. The old access offset relocation is covered by FIELD_BYTE_OFFSET = 0. An example: struct s { int a; int b1:9; int b2:4; }; enum { FIELD_BYTE_OFFSET = 0, FIELD_BYTE_SIZE, FIELD_EXISTENCE, FIELD_SIGNEDNESS, FIELD_LSHIFT_U64, FIELD_RSHIFT_U64, }; void bpf_probe_read(void *, unsigned, const void *); int field_read(struct s *arg) { unsigned long long ull = 0; unsigned offset = __builtin_preserve_field_info(arg->b2, FIELD_BYTE_OFFSET); unsigned size = __builtin_preserve_field_info(arg->b2, FIELD_BYTE_SIZE); #ifdef USE_PROBE_READ bpf_probe_read(&ull, size, (const void *)arg + offset); unsigned lshift = __builtin_preserve_field_info(arg->b2, FIELD_LSHIFT_U64); #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ lshift = lshift + (size << 3) - 64; #endif #else switch(size) { case 1: ull = *(unsigned char *)((void *)arg + offset); break; case 2: ull = *(unsigned short *)((void *)arg + offset); break; case 4: ull = *(unsigned int *)((void *)arg + offset); break; case 8: ull = *(unsigned long long *)((void *)arg + offset); break; } unsigned lshift = __builtin_preserve_field_info(arg->b2, FIELD_LSHIFT_U64); #endif ull <<= lshift; if (__builtin_preserve_field_info(arg->b2, FIELD_SIGNEDNESS)) return (long long)ull >> __builtin_preserve_field_info(arg->b2, FIELD_RSHIFT_U64); return ull >> __builtin_preserve_field_info(arg->b2, FIELD_RSHIFT_U64); } There is a minor overhead for bpf_probe_read() on big endian. The code and relocation generated for field_read where bpf_probe_read() is used to access argument data on little endian mode: r3 = r1 r1 = 0 r1 = 4 <=== relocation (FIELD_BYTE_OFFSET) r3 += r1 r1 = r10 r1 += -8 r2 = 4 <=== relocation (FIELD_BYTE_SIZE) call bpf_probe_read r2 = 51 <=== relocation (FIELD_LSHIFT_U64) r1 = *(u64 *)(r10 - 8) r1 <<= r2 r2 = 60 <=== relocation (FIELD_RSHIFT_U64) r0 = r1 r0 >>= r2 r3 = 1 <=== relocation (FIELD_SIGNEDNESS) if r3 == 0 goto LBB0_2 r1 s>>= r2 r0 = r1 LBB0_2: exit Compare to the above code between relocations FIELD_LSHIFT_U64 and FIELD_LSHIFT_U64, the code with big endian mode has four more instructions. r1 = 41 <=== relocation (FIELD_LSHIFT_U64) r6 += r1 r6 += -64 r6 <<= 32 r6 >>= 32 r1 = *(u64 *)(r10 - 8) r1 <<= r6 r2 = 60 <=== relocation (FIELD_RSHIFT_U64) The code and relocation generated when using direct load. r2 = 0 r3 = 4 r4 = 4 if r4 s> 3 goto LBB0_3 if r4 == 1 goto LBB0_5 if r4 == 2 goto LBB0_6 goto LBB0_9 LBB0_6: # %sw.bb1 r1 += r3 r2 = *(u16 *)(r1 + 0) goto LBB0_9 LBB0_3: # %entry if r4 == 4 goto LBB0_7 if r4 == 8 goto LBB0_8 goto LBB0_9 LBB0_8: # %sw.bb9 r1 += r3 r2 = *(u64 *)(r1 + 0) goto LBB0_9 LBB0_5: # %sw.bb r1 += r3 r2 = *(u8 *)(r1 + 0) goto LBB0_9 LBB0_7: # %sw.bb5 r1 += r3 r2 = *(u32 *)(r1 + 0) LBB0_9: # %sw.epilog r1 = 51 r2 <<= r1 r1 = 60 r0 = r2 r0 >>= r1 r3 = 1 if r3 == 0 goto LBB0_11 r2 s>>= r1 r0 = r2 LBB0_11: # %sw.epilog exit Considering verifier is able to do limited constant propogation following branches. The following is the code actually traversed. r2 = 0 r3 = 4 <=== relocation r4 = 4 <=== relocation if r4 s> 3 goto LBB0_3 LBB0_3: # %entry if r4 == 4 goto LBB0_7 LBB0_7: # %sw.bb5 r1 += r3 r2 = *(u32 *)(r1 + 0) LBB0_9: # %sw.epilog r1 = 51 <=== relocation r2 <<= r1 r1 = 60 <=== relocation r0 = r2 r0 >>= r1 r3 = 1 if r3 == 0 goto LBB0_11 r2 s>>= r1 r0 = r2 LBB0_11: # %sw.epilog exit For native load case, the load size is calculated to be the same as the size of load width LLVM otherwise used to load the value which is then used to extract the bitfield value. Differential Revision: https://reviews.llvm.org/D67980 llvm-svn: 374099
* [NFC] Attempt to make ubsan-blacklist-vfs test pass on WindowsJan Korous2019-10-081-4/+2
| | | | | | Previously disabled in d0c2d5daa3e llvm-svn: 374098
* [NFC] Fix ubsan-blacklist testJan Korous2019-10-082-11/+38
| | | | | | Restored original test and marked tests for VFS as unsupported on Windows. llvm-svn: 374011
* Reland 'Add VFS support for sanitizers' blacklist'Jan Korous2019-10-082-0/+26
| | | | | | | | | | The original patch broke the test for Windows. Trying to fix as per Reid's suggestions outlined here: https://reviews.llvm.org/rC371663 Differential Revision: https://reviews.llvm.org/D67742 llvm-svn: 374006
* Revert "Add VFS support for sanitizers' blacklist"Jan Korous2019-10-082-26/+0
| | | | | | | | Fix tests on Windows for now. This reverts commit 96ac97a4213287003f08636d0c372b3f71e9cfca. llvm-svn: 373999
* Add VFS support for sanitizers' blacklistJan Korous2019-10-072-0/+26
| | | | | | Differential Revision: https://reviews.llvm.org/D67742 llvm-svn: 373977
* [InstCombine] don't assume 'inbounds' for bitcast pointer to GEP transform ↵Sanjay Patel2019-10-061-36/+36
| | | | | | | | | | | | (PR43501) https://bugs.llvm.org/show_bug.cgi?id=43501 We can't declare a GEP 'inbounds' in general. But we may salvage that information if we have known dereferenceable bytes on the source pointer. Differential Revision: https://reviews.llvm.org/D68244 llvm-svn: 373847
* [clang] Prevent false positives in arm-mfpu-none codegen test.Simon Tatham2019-10-041-0/+1
| | | | | | | | | | | | | | | | | A user pointed out to me in private email that this test will fail if it sees the letter 's' followed by a digit in any part of clang's assembly output after the function label. That includes the .ident at the end, which can include a full pathname or hostname or both from the system clang was built on. So if that path or hostname includes any text like 's5' then it will cause the test to fail. Fixed by adding a check for `.fnend`, to limit the scope of the `CHECK-NOT` to only the actual generated code for the test function. (Committed without prior review on the basis that it's a simple and obvious pure test-suite fix and also in a test I contributed myself.) llvm-svn: 373744
* [clang] [AST] Treat "inline gnu_inline" the same way as "extern inline ↵Martin Storsjo2019-09-271-1/+2
| | | | | | | | | | | | | | | | | gnu_inline" in C++ mode This matches how GCC handles it, see e.g. https://gcc.godbolt.org/z/HPplnl. GCC documents the gnu_inline attribute with "In C++, this attribute does not depend on extern in any way, but it still requires the inline keyword to enable its special behavior." The previous behaviour of gnu_inline in C++, without the extern keyword, can be traced back to the original commit that added support for gnu_inline, SVN r69045. Differential Revision: https://reviews.llvm.org/D67414 llvm-svn: 373078
* [test] Use %clang_cc1 instead of %clang -cc1Fangrui Song2019-09-271-1/+1
| | | | llvm-svn: 373043
* [x86] Adding support for some missing intrinsics: _castf32_u32, ↵Pengfei Wang2019-09-251-0/+45
| | | | | | | | | | | | | | | | | | | | _castf64_u64, _castu32_f32, _castu64_f64 Summary: Adding support for some missing intrinsics: _castf32_u32, _castf64_u64, _castu32_f32, _castu64_f64 Reviewers: craig.topper, LuoYuanke, RKSimon, pengfei Reviewed By: RKSimon Subscribers: llvm-commits Patch by yubing (Bing Yu) Differential Revision: https://reviews.llvm.org/D67212 llvm-svn: 372802
* [CLANG][BPF] permit any argument type for __builtin_preserve_access_index()Yonghong Song2019-09-221-0/+18
| | | | | | | | | | | | | | | | | | | | Commit c15aa241f821 ("[CLANG][BPF] change __builtin_preserve_access_index() signature") changed the builtin function signature to PointerT __builtin_preserve_access_index(PointerT ptr) with a pointer type as the argument/return type, where argument and return types must be the same. There is really no reason for this constraint. The builtin just presented a code region so that IR builtins __builtin_{array, struct, union}_preserve_access_index can be applied. This patch removed the pointer type restriction to permit any argument type as long as it is permitted by the compiler. Differential Revision: https://reviews.llvm.org/D67883 llvm-svn: 372516
* [SystemZ] Support z15 processor nameUlrich Weigand2019-09-207-5/+11
| | | | | | | | | | The recently announced IBM z15 processor implements the architecture already supported as "arch13" in LLVM. This patch adds support for "z15" as an alternate architecture name for arch13. Corrsponding LLVM support was committed as rev. 372435. llvm-svn: 372436
* [X86] Prevent assertion when calling a function that returns double with ↵Craig Topper2019-09-181-0/+20
| | | | | | | | -mno-sse2 on x86-64. As seen in the most recent updates to PR10498 llvm-svn: 372197
* [ARM] Update clang for removal of vfp2d16 and vfp2d16spEli Friedman2019-09-171-14/+14
| | | | | | | | Matching fix for https://reviews.llvm.org/D67375 (r372186). Differential Revision: https://reviews.llvm.org/D67467 llvm-svn: 372187
* [NFC] Updated testDavid Bolvansky2019-09-171-7/+7
| | | | llvm-svn: 372095
* Fix reliance on -flax-vector-conversions in AVX intrinsics headers andRichard Smith2019-09-173-14/+14
| | | | | | corresponding tests. llvm-svn: 372063
* Fix reliance on lax vector conversions in tests for x86 intrinsics.Richard Smith2019-09-176-13/+13
| | | | llvm-svn: 372062
* Remove reliance on lax vector conversions from altivec.h in VSX mode.Richard Smith2019-09-174-4/+21
| | | | llvm-svn: 372061
* [Clang][Codegen] Disable arm_acle.c test.Roman Lebedev2019-09-161-0/+2
| | | | | | | | | | This test is broken by design. Clang codegen tests should not depend on llvm middle-end behaviour, they should *only* test clang codegen. Yet this test runs whole optimization pipeline. I've really tried to fix it, but there isn't just a few things that depend on passes, but everything there does. llvm-svn: 372015
* [Clang][Codegen] Relax available-externally-suppress.c testRoman Lebedev2019-09-161-2/+0
| | | | | | | | | That test is broken by design. It depends on llvm middle-end behavior. No clang codegen test should be doing that. This one is salvageable by relaxing check lines. llvm-svn: 372014
* Change signature of __builtin_rotateright64 back to unsignedKarl-Johan Karlsson2019-09-161-0/+4
| | | | | | | | | | | | | | | | The signature of __builtin_rotateright64 was by misstake changed from unsigned to signed in r360863, this patch will change it back to unsigned as intended. This fixes pr43309 Reviewers: efriedma, hans Reviewed By: hans Differential Revision: https://reviews.llvm.org/D67606 llvm-svn: 371969
* [WebAssembly] Narrowing and widening SIMD opsThomas Lively2019-09-131-0/+76
| | | | | | | | | | | | | | | | Summary: Implements target-specific LLVM intrinsics and clang builtins for these new SIMD operations, as described at https://github.com/WebAssembly/simd/blob/master/proposals/simd/SIMD.md#integer-to-integer-narrowing. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D67425 llvm-svn: 371906
* For PR17164: split -fno-lax-vector-conversion into three differentRichard Smith2019-09-1311-18/+18
| | | | | | | | | | | | | | | | | | | | | levels: -- none: no lax vector conversions [new GCC default] -- integer: only conversions between integer vectors [old GCC default] -- all: all conversions between same-size vectors [Clang default] For now, Clang still defaults to "all" mode, but per my proposal on cfe-dev (2019-04-10) the default will be changed to "integer" as soon as that doesn't break lots of testcases. (Eventually I'd like to change the default to "none" to match GCC and general sanity.) Following GCC's behavior, the driver flag -flax-vector-conversions is translated to -flax-vector-conversions=integer. This reinstates r371805, reverted in r371813, with an additional fix for lldb. llvm-svn: 371817
* Fix interaction between r371813 and r371814.Richard Smith2019-09-131-3/+3
| | | | llvm-svn: 371816
* Remove reliance on lax vector conversions from altivec.h and its test.Richard Smith2019-09-131-13/+13
| | | | llvm-svn: 371814
* Revert "For PR17164: split -fno-lax-vector-conversion into three different"Jonas Devlieghere2019-09-1310-15/+15
| | | | | | | This breaks the LLDB build. I tried reaching out to Richard, but haven't gotten a reply yet. llvm-svn: 371813
* For PR17164: split -fno-lax-vector-conversion into three differentRichard Smith2019-09-1310-15/+15
| | | | | | | | | | | | | | | | | | levels: -- none: no lax vector conversions [new GCC default] -- integer: only conversions between integer vectors [old GCC default] -- all: all conversions between same-size vectors [Clang default] For now, Clang still defaults to "all" mode, but per my proposal on cfe-dev (2019-04-10) the default will be changed to "integer" as soon as that doesn't break lots of testcases. (Eventually I'd like to change the default to "none" to match GCC and general sanity.) Following GCC's behavior, the driver flag -flax-vector-conversions is translated to -flax-vector-conversions=integer. llvm-svn: 371805
* Improve code generation for thread_local variables:Richard Smith2019-09-121-11/+0
| | | | | | | | | | | | | | | | | | | | | Summary: * Don't bother using a thread wrapper when the variable is known to have constant initialization. * Emit the thread wrapper as discardable-if-unused in TUs that don't contain a definition of the thread_local variable. * Don't emit the thread wrapper at all if the thread_local variable is unused and discardable; it will be emitted by all TUs that need it. Reviewers: rjmccall, jdoerfert Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67429 llvm-svn: 371767
* [Clang][CodeGen] support alias attribute w/ gnu_inlineNick Desaulniers2019-09-121-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: r369705 did not consider the addition of gnu_inline on function declarations of alias attributed functions. This resulted in a reported regression in the clang-9-rc4 release from the Zig developers building glibc, which was observable as a failed assertion: llvm-project/clang/lib/AST/Decl.cpp:3336: bool clang::FunctionDecl::isInlineDefinitionExternallyVisible() const: Assertion `(doesThisDeclarationHaveABody() || willHaveBody()) && "Must be a function definition"' failed. Alias function declarations do not have bodies, so allow us to proceed if we have the alias function attribute but no body/definition, and add a test case. The emitted symbols and their linkage matches GCC for the added test case. Link: https://bugs.llvm.org/show_bug.cgi?id=43268 Reviewers: aaron.ballman, rsmith, erichkeane, andrewrk Reviewed By: andrewrk Subscribers: cfe-commits, andrewrk, hans, srhines Tags: #clang Differential Revision: https://reviews.llvm.org/D67455 llvm-svn: 371766
* [CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver ↵Fangrui Song2019-09-114-45/+61
| | | | | | | | | | | | | | linkage type Multi-versioned functions defined by cpu_dispatch and implemented with IFunc can not be called outside the translation units where they are defined due to lack of symbols. This patch add function aliases for these functions and thus make them visible outside. Differential Revision: https://reviews.llvm.org/D67058 Patch by Senran Zhang llvm-svn: 371586
* Reland "Change the X86 datalayout to add three address spacesAmy Huang2019-09-1014-21/+20
| | | | | | | | | | for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568
* Re-land Remove REQUIRES:shell from tests that pass for me on WindowsReid Kleckner2019-09-101-4/+7
| | | | | | | | | | | | This reverts r371497 (git commit 3d7e9ab7b9f8c53aa41420c54970f0fb421004a2) Reorder `not` with `env` in these two tests so they pass: Driver/rewrite-map-in-diagnostics.c Index/crash-recovery-modules.m. This will not be necessary after D66531 lands. llvm-svn: 371552
* Revert Remove REQUIRES:shell from tests that pass for me on WindowsJames Henderson2019-09-101-7/+4
| | | | | | This reverts r371478 (git commit a9980f60ce083fa6d5fd03c12c58ca0b293e3d60) llvm-svn: 371497
* Remove REQUIRES:shell from tests that pass for me on WindowsReid Kleckner2019-09-101-4/+7
| | | | | | | | | | | | | I see in the history for some of these tests REQUIRES:shell was used as a way to disable tests on Windows because they are flaky there. I tried not to re-enable such tests, but it's possible that I missed some and this will re-enable flaky tests on Windows. If so, we should disable them with UNSUPPORTED:system-windows and add a comment that they are flaky there. So far as I can tell, the lit internal shell is capable of running all of these tests, and we shouldn't use REQUIRES:shell as a proxy for Windows. llvm-svn: 371478
* [NFC] Add aacps bitfields access testDiogo N. Sampaio2019-09-091-0/+824
| | | | llvm-svn: 371410
* [X86] Prevent passing vectors of __int128 as <X x i128> in llvm IRCraig Topper2019-09-061-3/+6
| | | | | | | | | | | | | As far as I can tell, gcc passes 256/512 bit vectors __int128 in memory. And passes a vector of 1 _int128 in an xmm register. The backend considers <X x i128> as an illegal type and will scalarize any arguments with that type. So we need to coerce the argument types in the frontend to match to avoid the illegal type. I'm restricting this to change to Linux and NetBSD based on the how similar ABI changes have been handled in the past. PS4, FreeBSD, and Darwin are unaffected. I've also added a new -fclang-abi-compat version to restore the old behavior. This issue was identified in PR42607. Though even with the types changed, we still seem to be doing some unnecessary stack realignment. llvm-svn: 371169
* [X86] Pre-commit vector of __int128 test cases for D64672.Craig Topper2019-09-061-0/+49
| | | | llvm-svn: 371168
OpenPOWER on IntegriCloud