summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Don't keep stale pointers to LoopInfos.Aaron Ballman2019-08-191-0/+16
| | | | | | | | CGLoopInfo was keeping pointers to parent loop LoopInfos, but when the loop info vector grew, it reallocated the storage and invalidated all of the parent pointers, causing use-after-free. Manage the lifetimes of the LoopInfos separately so that the pointers aren't stale. Patch by Bevin Hansson. llvm-svn: 369259
* [RISCV] Add inline asm constraint A for RISC-VLewis Revill2019-08-161-0/+6
| | | | | | | | | | | | This allows the constraint A to be used in inline asm for RISC-V, which allows an address held in a register to be used. This patch adds the minimal amount of code required to get operands with the right constraints to compile. Differential Revision: https://reviews.llvm.org/D54295 llvm-svn: 369093
* [WebAssembly] Correctly handle va_arg of zero-sized structuresGuanzhong Chen2019-08-151-18/+58
| | | | | | | | | | | | | | | | | | | | | Summary: D66168 passes size 0 structs indirectly, while the wasm backend expects it to be passed directly. This causes subsequent variadic arguments to be read incorrectly. This diff changes it so that size 0 structs are passed directly. Reviewers: dschuff, tlively, sbc100 Reviewed By: dschuff Subscribers: jgravelle-google, aheejin, sunfish, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66255 llvm-svn: 369042
* [X86] Add test cases for _mm_movepi64_pi64 and _mm_movpi64_epi64.Craig Topper2019-08-151-0/+17
| | | | llvm-svn: 368969
* [NFC] Updated tests after r368875David Bolvansky2019-08-141-7/+7
| | | | llvm-svn: 368876
* [NFC] Fix testcase for ARMsDavid Bolvansky2019-08-141-3/+3
| | | | llvm-svn: 368863
* [NFC] Make test more robustDavid Bolvansky2019-08-141-27/+5
| | | | | | Currently fails on ARMs llvm-svn: 368828
* [Codegen] Updated test for D66158David Bolvansky2019-08-141-2/+34
| | | | | | | | | | | | | | Reviewers: jdoerfert Reviewed By: jdoerfert Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66173 llvm-svn: 368809
* [WebAssembly] Make clang emit correct va_arg code for structsGuanzhong Chen2019-08-131-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In the WebAssembly backend, when lowering variadic function calls, non-single member aggregate type arguments are always passed by pointer. However, when emitting va_arg code in clang, the arguments are instead read as if they are passed directly. This results in the pointer being read as the actual structure. Fixes https://github.com/emscripten-core/emscripten/issues/9042. Reviewers: tlively, sbc100, kripken, aheejin, dschuff Reviewed By: dschuff Subscribers: dschuff, jgravelle-google, sunfish, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66168 llvm-svn: 368750
* [NFC] Updated tests after r368724David Bolvansky2019-08-131-7/+7
| | | | llvm-svn: 368725
* [NFC] Updated tests after r368657David Bolvansky2019-08-131-7/+7
| | | | llvm-svn: 368658
* cfi-icall: Allow the jump table to be optionally made non-canonical.Peter Collingbourne2019-08-092-4/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default behavior of Clang's indirect function call checker will replace the address of each CFI-checked function in the output file's symbol table with the address of a jump table entry which will pass CFI checks. We refer to this as making the jump table `canonical`. This property allows code that was not compiled with ``-fsanitize=cfi-icall`` to take a CFI-valid address of a function, but it comes with a couple of caveats that are especially relevant for users of cross-DSO CFI: - There is a performance and code size overhead associated with each exported function, because each such function must have an associated jump table entry, which must be emitted even in the common case where the function is never address-taken anywhere in the program, and must be used even for direct calls between DSOs, in addition to the PLT overhead. - There is no good way to take a CFI-valid address of a function written in assembly or a language not supported by Clang. The reason is that the code generator would need to insert a jump table in order to form a CFI-valid address for assembly functions, but there is no way in general for the code generator to determine the language of the function. This may be possible with LTO in the intra-DSO case, but in the cross-DSO case the only information available is the function declaration. One possible solution is to add a C wrapper for each assembly function, but these wrappers can present a significant maintenance burden for heavy users of assembly in addition to adding runtime overhead. For these reasons, we provide the option of making the jump table non-canonical with the flag ``-fno-sanitize-cfi-canonical-jump-tables``. When the jump table is made non-canonical, symbol table entries point directly to the function body. Any instances of a function's address being taken in C will be replaced with a jump table address. This scheme does have its own caveats, however. It does end up breaking function address equality more aggressively than the default behavior, especially in cross-DSO mode which normally preserves function address equality entirely. Furthermore, it is occasionally necessary for code not compiled with ``-fsanitize=cfi-icall`` to take a function address that is valid for CFI. For example, this is necessary when a function's address is taken by assembly code and then called by CFI-checking C code. The ``__attribute__((cfi_jump_table_canonical))`` attribute may be used to make the jump table entry of a specific function canonical so that the external code will end up taking a address for the function that will pass CFI checks. Fixes PR41972. Differential Revision: https://reviews.llvm.org/D65629 llvm-svn: 368495
* CodeGen: ensure 8-byte aligned String Swift CF ABISaleem Abdulrasool2019-08-091-0/+6
| | | | | | | | | CFStrings should be 8-byte aligned when built for the Swift CF runtime ABI as the atomic CF info field must be properly aligned. This is a problem on 32-bit platforms which would give the structure 4-byte alignment rather than 8-byte alignment. llvm-svn: 368471
* Add SVE opaque built-in typesRichard Sandiford2019-08-091-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PowerPC] [Clang] Port SSE3, SSSE3 and SSE4 intrinsics to PowerPCQiu Chaofan2019-08-093-0/+1332
| | | | | | | | | | | | | | | Port existing headers which include x86 intrinsics implementation to PowerPC platform (using Altivec), along with tests. Also, tests about including these intrinsic headers are combined. The headers are mainly developed by Steven Munroe, with contributions from Paul Clarke, Bill Schmidt, Jinsong Ji and Zixuan Wu. Reviewed By: Jinsong Ji Differential Revision: https://reviews.llvm.org/D65630 llvm-svn: 368392
* Add target requirements for those bots which don't handle x86.Bill Wendling2019-08-071-0/+1
| | | | llvm-svn: 368202
* Delay diagnosing asm constraints that require immediates until after inliningBill Wendling2019-08-061-0/+19
| | | | | | | | | | | | | | | | Summary: An inline asm call may result in an immediate input value after inlining. Therefore, don't emit a diagnostic here if the input isn't an immediate. Reviewers: joerg, eli.friedman, rsmith Subscribers: asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, s.egerton, krytarowski, mgorny, riccibruno, eraman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60943 llvm-svn: 368104
* [WebAssembly] Lower ASan constructor priority on EmscriptenGuanzhong Chen2019-08-061-0/+5
| | | | | | | | | | | | | | | | | | | | | | | Summary: This change gives Emscripten the ability to use more than one constructor priorities that runs before ASan. By convention, constructor priorites 0-100 are reserved for use by the system. ASan on Emscripten now uses priority 50, leaving plenty of room for use by Emscripten before and after ASan. This change is done in response to: https://github.com/emscripten-core/emscripten/pull/9076#discussion_r310323723 Reviewers: kripken, tlively, aheejin Reviewed By: tlively Subscribers: cfe-commits, dschuff, sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D65684 llvm-svn: 368101
* Sidestep false positive due to a matching git repository nameRoger Ferrer Ibanez2019-08-051-1/+1
| | | | | | | | | | | | | | | I have failures in this test because the grep @b gets confused by the clang version including a repository name like this !1 = !{!"clang version 10.0.0 (git@build-machine:llvm/llvm-monorepo.git fe958c0e8c89ec663c8e551936778e2cbb460154)"} I considered something like grep -w but my understanding of the manpages was that that isn't super portable. So I think it is easier to make clang not to output that metadata using -fno-ident. Differential Revision: https://reviews.llvm.org/D65635 llvm-svn: 367826
* IR: print value numbers for unnamed function argumentsTim Northover2019-08-0339-295/+295
| | | | | | | | | | For consistency with normal instructions and clarity when reading IR, it's best to print the %0, %1, ... names of function arguments in definitions. Also modifies the parser to accept IR in that form for obvious reasons. llvm-svn: 367755
* [BPF] annotate DIType metadata for builtin preseve_array_access_index()Yonghong Song2019-08-022-11/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, debuginfo types are annotated to IR builtin preserve_struct_access_index() and preserve_union_access_index(), but not preserve_array_access_index(). The debug info is useful to identify the root type name which later will be used for type comparison. For user access without explicit type conversions, the previous scheme works as we can ignore intermediate compiler generated type conversions (e.g., from union types to union members) and still generate correct access index string. The issue comes with user explicit type conversions, e.g., converting an array to a structure like below: struct t { int a; char b[40]; }; struct p { int c; int d; }; struct t *var = ...; ... __builtin_preserve_access_index(&(((struct p *)&(var->b[0]))->d)) ... Although BPF backend can derive the type of &(var->b[0]), explicit type annotation make checking more consistent and less error prone. Another benefit is for multiple dimension array handling. For example, struct p { int c; int d; } g[8][9][10]; ... __builtin_preserve_access_index(&g[2][3][4].d) ... It would be possible to calculate the number of "struct p"'s before accessing its member "d" if array debug info is available as it contains each dimension range. This patch enables to annotate IR builtin preserve_array_access_index() with proper debuginfo type. The unit test case and language reference is updated as well. Signed-off-by: Yonghong Song <yhs@fb.com> Differential Revision: https://reviews.llvm.org/D65664 llvm-svn: 367724
* Rename two clang tests from .cc to .cpp.Nico Weber2019-08-011-0/+0
| | | | | | | | | | clang/test/lit.cfg.py doesn't list .cc as test extension, so these tests never ran. Tweak one of the two tests to actually pass, now that it runs. (The other one was already passing.) llvm-svn: 367574
* [clang][ARM] Fix msvc arm{64} builtins to use int on LP64 systems.Michael J. Spencer2019-07-312-0/+226
| | | | | | | | | | | | The `InterlockedX_{acq,nf,rel}` functions deal with 32 bits which is long on MSVC, but int on most other systems. This also checks that `ReadStatusRegister` and `WriteStatusRegister` have the correct type on aarch64-darwin. Differential Revision: https://reviews.llvm.org/D64164 llvm-svn: 367479
* [InstCombine] canonicalize fneg before fmul/fdivSanjay Patel2019-07-311-12/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reverse the canonicalization of fneg relative to fmul/fdiv. That makes it easier to implement the transforms (and possibly other fneg transforms) in 1 place because we can always start the pattern match from fneg (either the legacy binop or the new unop). There's a secondary practical benefit seen in PR21914 and PR42681: https://bugs.llvm.org/show_bug.cgi?id=21914 https://bugs.llvm.org/show_bug.cgi?id=42681 ...hoisting fneg rather than sinking seems to play nicer with LICM in IR (although this change may expose analysis holes in the other direction). 1. The instcombine test changes show the expected neutral IR diffs from reversing the order. 2. The reassociation tests show that we were missing an optimization opportunity to fold away fneg-of-fneg. My reading of IEEE-754 says that all of these transforms are allowed (regardless of binop/unop fneg version) because: "For all other operations [besides copy/abs/negate/copysign], this standard does not specify the sign bit of a NaN result." In all of these transforms, we always have some other binop (fadd/fsub/fmul/fdiv), so we are free to flip the sign bit of a potential intermediate NaN operand. (If that interpretation is wrong, then we must already have a bug in the existing transforms?) 3. The clang tests shouldn't exist as-is, but that's effectively a revert of rL367149 (the test broke with an extension of the pre-existing fneg canonicalization in rL367146). Differential Revision: https://reviews.llvm.org/D65399 llvm-svn: 367447
* [AArch64] Add support for Transactional Memory Extension (TME)Momchil Velikov2019-07-311-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | Re-commit r366322 after some fixes TME is a future architecture technology, documented in https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools https://developer.arm.com/docs/ddi0601/a More about the future architectures: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture This patch adds support for the TME instructions TSTART, TTEST, TCOMMIT, and TCANCEL and the target feature/arch extension "tme". It also implements TME builtin functions, defined in ACLE Q2 2019 (https://developer.arm.com/docs/101028/latest) Differential Revision: https://reviews.llvm.org/D64416 Patch by Javed Absar and Momchil Velikov llvm-svn: 367428
* [RISCV] Support 'f' Inline Assembly ConstraintSam Elliott2019-07-311-0/+12
| | | | | | | | | | | | | | | | | | | | | | | Summary: This adds the 'f' inline assembly constraint, as supported by GCC. An 'f'-constrained operand is passed in a floating point register. Exactly which kind of floating-point register (32-bit or 64-bit) is decided based on the operand type and the available standard extensions (-f and -d, respectively). This patch adds support in both the clang frontend, and LLVM itself. Reviewers: asb, lewis-revill Reviewed By: asb Subscribers: hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65500 llvm-svn: 367403
* [COFF][ARM64] Reorder handling of aarch64 MSVC builtinsDavid Major2019-07-301-0/+4
| | | | | | | | | | In `CodeGenFunction::EmitAArch64BuiltinExpr()`, bulk move all of the aarch64 MSVC-builtin cases to an earlier point in the function (the `// Handle non-overloaded intrinsics first` switch block) in order to avoid an unreachable in `GetNeonType()`. The NEON type-overloading logic is not appropriate for the Windows builtins. Fixes https://llvm.org/pr42775 Differential Revision: https://reviews.llvm.org/D65403 llvm-svn: 367323
* [FunctionAttrs] Annotate "willreturn" for intrinsicsHideto Ueno2019-07-281-1/+1
| | | | | | | | | | | | | | | | | | | Summary: In D62801, new function attribute `willreturn` was introduced. In short, a function with `willreturn` is guaranteed to come back to the call site(more precise definition is in LangRef). In this patch, willreturn is annotated for LLVM intrinsics. Reviewers: jdoerfert Reviewed By: jdoerfert Subscribers: jvesely, nhaehnle, sstefan1, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64904 llvm-svn: 367184
* Revert "[ARM] Set default alignment to 64bits"Petr Hosek2019-07-271-19/+0
| | | | | | | | | | | This reverts commit r367119. This broke several bots: http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/26891/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Aexception-alignment.cpp http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/245/consoleFull llvm-svn: 367166
* [NewPM] Run avx*-builtins.c tests under the new pass manager onlyLeonard Chan2019-07-264-150/+280
| | | | | | | | | | | | | | | | | | | | This patch changes the following tests to run under the new pass manager only: ``` Clang :: CodeGen/avx512-reduceMinMaxIntrin.c (1 of 4) Clang :: CodeGen/avx512vl-builtins.c (2 of 4) Clang :: CodeGen/avx512vlbw-builtins.c (3 of 4) Clang :: CodeGen/avx512f-builtins.c (4 of 4) ``` The new PM added extra bitcasts that weren't checked before. For reduceMinMaxIntrin.c, the issue was mostly the alloca's being in a different order. Other changes involved extra bitcasts, and differently ordered loads and stores, but the logic should still be the same. Differential revision: https://reviews.llvm.org/D65110 llvm-svn: 367157
* [CodeGen] fix test that broke with rL367146Sanjay Patel2019-07-261-12/+11
| | | | | | This should be fixed properly to not depend on LLVM (so much). llvm-svn: 367149
* [ARM] Set default alignment to 64bitsSimi Pallipurath2019-07-261-0/+19
| | | | | | | | | | | | | | | | | | The maximum alignment used by ARM arch is 64bits, not 128. This could cause overaligned memory access for 128 bit neon vector that have unpredictable behaviour. This fixes: https://bugs.llvm.org/show_bug.cgi?id=42668 Patch by: Diogo Sampaio(diogo.sampaio@arm.com) Differential Revision: https://reviews.llvm.org/D65000 Change-Id: I5a62b766491f15dd51e4cfe6625929db897f67e3 llvm-svn: 367119
* Reland the "[NewPM] Port Sancov" patch from rL365838. No functionalLeonard Chan2019-07-251-0/+41
| | | | | | | | | | | | | | | | | | | | | changes were made to the patch since then. -------- [NewPM] Port Sancov This patch contains a port of SanitizerCoverage to the new pass manager. This one's a bit hefty. Changes: - Split SanitizerCoverageModule into 2 SanitizerCoverage for passing over functions and ModuleSanitizerCoverage for passing over modules. - ModuleSanitizerCoverage exists for adding 2 module level calls to initialization functions but only if there's a function that was instrumented by sancov. - Added legacy and new PM wrapper classes that own instances of the 2 new classes. - Update llvm tests and add clang tests. llvm-svn: 367053
* Allow prefetching from non-zero address spacesJF Bastien2019-07-258-22/+27
| | | | | | | | | | | | | | | Summary: This is useful for targets which have prefetch instructions for non-default address spaces. <rdar://problem/42662136> Subscribers: nemanjai, javed.absar, hiraditya, kbarton, jkorous, dexonsmith, cfe-commits, llvm-commits, RKSimon, hfinkel, t.p.northover, craig.topper, anemet Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65254 llvm-svn: 367032
* [SVE][Inline-Asm] Add support to specify SVE registers in the clobber listSander de Smalen2019-07-241-0/+13
| | | | | | | | | | | | | | Adds the SVE vector and predicate registers to the list of known registers. Patch by Kerry McLaughlin. Reviewers: erichkeane, sdesmalen, rengolin Reviewed By: sdesmalen Differential Revision: https://reviews.llvm.org/D64739 llvm-svn: 366878
* Updated the signature for some stack related intrinsics (CLANG)Christudasan Devadasan2019-07-225-12/+12
| | | | | | | | | | | | | Modified the intrinsics int_addressofreturnaddress, int_frameaddress & int_sponentry. This commit depends on the changes in rL366679 Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D64563 llvm-svn: 366683
* [Clang] Replace cc1 options '-mdisable-fp-elim' and '-momit-leaf-frame-pointer'Yuanfang Chen2019-07-204-6/+6
| | | | | | | | | | | | | | | | with '-mframe-pointer' After D56351 and D64294, frame pointer handling is migrated to tri-state (all, non-leaf, none) in clang driver and on the function attribute. This patch makes the frame pointer handling cc1 option tri-state. Reviewers: chandlerc, rnk, t.p.northover, MaskRay Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D56353 llvm-svn: 366645
* [WebAssembly] Compute and export TLS block alignmentGuanzhong Chen2019-07-191-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add immutable WASM global `__tls_align` which stores the alignment requirements of the TLS segment. Add `__builtin_wasm_tls_align()` intrinsic to get this alignment in Clang. The expected usage has now changed to: __wasm_init_tls(memalign(__builtin_wasm_tls_align(), __builtin_wasm_tls_size())); Reviewers: tlively, aheejin, sbc100, sunfish, alexcrichton Reviewed By: tlively Subscribers: dschuff, jgravelle-google, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65028 llvm-svn: 366624
* [LTO] Always mark regular LTO units with EnableSplitLTOUnit=1Teresa Johnson2019-07-191-0/+12
| | | | | | | | | | | | | | | | | | | Summary: Regular LTO modules do not need LTO Unit splitting, only ThinLTO does (they must be consistently split into regular and Thin units for optimizations such as whole program devirtualization and lower type tests). In order to avoid spurious errors from LTO when combining with split ThinLTO modules, always set this flag for regular LTO modules. Reviewers: pcc Subscribers: mehdi_amini, Prazek, inglorion, steven_wu, dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65009 llvm-svn: 366623
* [RISCV] Hard float ABI supportAlex Bradbury2019-07-189-2/+1153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The RISC-V hard float calling convention requires the frontend to: * Detect cases where, once "flattened", a struct can be passed using int+fp or fp+fp registers under the hard float ABI and coerce to the appropriate type(s) * Track usage of GPRs and FPRs in order to gate the above, and to determine when signext/zeroext attributes must be added to integer scalars This patch attempts to do this in compliance with the documented ABI, and uses ABIArgInfo::CoerceAndExpand in order to do this. @rjmccall, as author of that code I've tagged you as reviewer for initial feedback on my usage. Note that a previous version of the ABI indicated that when passing an int+fp struct using a GPR+FPR, the int would need to be sign or zero-extended appropriately. GCC never did this and the ABI was changed, which makes life easier as ABIArgInfo::CoerceAndExpand can't currently handle sign/zero-extension attributes. Re-landed after backing out 366450 due to missed hunks. Differential Revision: https://reviews.llvm.org/D60456 llvm-svn: 366480
* [WebAssembly] Implement __builtin_wasm_tls_base intrinsicGuanzhong Chen2019-07-181-0/+5
| | | | | | | | | | | | | | | | Summary: Add `__builtin_wasm_tls_base` so that LeakSanitizer can find the thread-local block and scan through it for memory leaks. Reviewers: tlively, aheejin, sbc100 Subscribers: dschuff, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D64900 llvm-svn: 366475
* Revert "[RISCV] Hard float ABI support" r366450Alex Bradbury2019-07-189-1153/+2
| | | | | | The commit was missing a few hunks. Will fix and recommit. llvm-svn: 366454
* [RISCV] Hard float ABI supportAlex Bradbury2019-07-189-2/+1153
| | | | | | | | | | | | | | | | | | | | | | | | | | The RISC-V hard float calling convention requires the frontend to: * Detect cases where, once "flattened", a struct can be passed using int+fp or fp+fp registers under the hard float ABI and coerce to the appropriate type(s) * Track usage of GPRs and FPRs in order to gate the above, and to determine when signext/zeroext attributes must be added to integer scalars This patch attempts to do this in compliance with the documented ABI, and uses ABIArgInfo::CoerceAndExpand in order to do this. @rjmccall, as author of that code I've tagged you as reviewer for initial feedback on my usage. Note that a previous version of the ABI indicated that when passing an int+fp struct using a GPR+FPR, the int would need to be sign or zero-extended appropriately. GCC never did this and the ABI was changed, which makes life easier as ABIArgInfo::CoerceAndExpand can't currently handle sign/zero-extension attributes. Differential Revision: https://reviews.llvm.org/D60456 llvm-svn: 366450
* [PowerPC][Clang] Remove use of malloc in mm_mallocQiu Chaofan2019-07-182-40/+8
| | | | | | | | | | | Remove dependency of malloc in implementation of mm_malloc function in PowerPC intrinsics and alignment assumption on glibc. Reviewed By: Hal Finkel Differential Revision: https://reviews.llvm.org/D64850 llvm-svn: 366406
* Renamed and changed the wording of warn_cconv_ignoredSunil Srivastava2019-07-171-2/+2
| | | | | | | | As discussed in D64780 the wording of this warning message is being changed to say 'is not supported' instead of 'ignored', and the diag ID itself is being changed to warn_cconv_not_supported. llvm-svn: 366368
* Revert [AArch64] Add support for Transactional Memory Extension (TME)Momchil Velikov2019-07-172-46/+0
| | | | | | This reverts r366322 (git commit 4b8da3a503e434ddbc08ecf66582475765f449bc) llvm-svn: 366355
* [AArch64] Add support for Transactional Memory Extension (TME)Momchil Velikov2019-07-172-0/+46
| | | | | | | | | | | | | | | | | | | | | | | TME is a future architecture technology, documented in https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools https://developer.arm.com/docs/ddi0601/a More about the future architectures: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture This patch adds support for the TME instructions TSTART, TTEST, TCOMMIT, and TCANCEL and the target feature/arch extension "tme". It also implements TME builtin functions, defined in ACLE Q2 2019 (https://developer.arm.com/docs/101028/latest) Patch by Javed Absar and Momchil Velikov Differential Revision: https://reviews.llvm.org/D64416 llvm-svn: 366322
* [WebAssembly] Implement thread-local storage (local-exec model)Guanzhong Chen2019-07-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Thread local variables are placed inside a `.tdata` segment. Their symbols are offsets from the start of the segment. The address of a thread local variable is computed as `__tls_base` + the offset from the start of the segment. `.tdata` segment is a passive segment and `memory.init` is used once per thread to initialize the thread local storage. `__tls_base` is a wasm global. Since each thread has its own wasm instance, it is effectively thread local. Currently, `__tls_base` must be initialized at thread startup, and so cannot be used with dynamic libraries. `__tls_base` is to be initialized with a new linker-synthesized function, `__wasm_init_tls`, which takes as an argument a block of memory to use as the storage for thread locals. It then initializes the block of memory and sets `__tls_base`. As `__wasm_init_tls` will handle the memory initialization, the memory does not have to be zeroed. To help allocating memory for thread-local storage, a new compiler intrinsic is introduced: `__builtin_wasm_tls_size()`. This instrinsic function returns the size of the thread-local storage for the current function. The expected usage is to run something like the following upon thread startup: __wasm_init_tls(malloc(__builtin_wasm_tls_size())); Reviewers: tlively, aheejin, kripken, sbc100 Subscribers: dschuff, jgravelle-google, hiraditya, sunfish, jfb, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D64537 llvm-svn: 366272
* fix unnamed fiefield issue and add tests for __builtin_preserve_access_index ↵Yonghong Song2019-07-161-0/+177
| | | | | | | | | | | | | | | | | | | | | | | | intrinsic The original commit is r366076. It is temporarily reverted (r366155) due to test failure. This resubmit makes test more robust by accepting regex instead of hardcoded names/references in several places. This is a followup patch for https://reviews.llvm.org/D61809. Handle unnamed bitfield properly and add more test cases. Fixed the unnamed bitfield issue. The unnamed bitfield is ignored by debug info, so we need to ignore such a struct/union member when we try to get the member index in the debug info. D61809 contains two test cases but not enough as it does not checking generated IRs in the fine grain level, and also it does not have semantics checking tests. This patch added unit tests for both code gen and semantics checking for the new intrinsic. Signed-off-by: Yonghong Song <yhs@fb.com> llvm-svn: 366231
* [AArch64] Implement __jcvt intrinsic from Armv8.3-AKyrylo Tkachov2019-07-162-0/+17
| | | | | | | | | | | | | | | | The jcvt intrinsic defined in ACLE [1] is available when ARM_FEATURE_JCVT is defined. This change introduces the AArch64 intrinsic, wires it up to the instruction and a new clang builtin function. The __ARM_FEATURE_JCVT macro is now defined when an Armv8.3-A or higher target is used. I've implemented the target detection logic in Clang so that this feature is enabled for architectures from armv8.3-a onwards (so -march=armv8.4-a also enables this, for example). make check-all didn't show any new failures. [1] https://developer.arm.com/docs/101028/latest/data-processing-intrinsics Differential Revision: https://reviews.llvm.org/D64495 llvm-svn: 366197
OpenPOWER on IntegriCloud