summaryrefslogtreecommitdiffstats
path: root/clang/test/Sema
Commit message (Collapse)AuthorAgeFilesLines
* [Sema] Allow function attribute patchable_function_entry on aarch64_beFangrui Song2020-05-061-0/+1
| | | | | | | | Reviewed By: nickdesaulniers Differential Revision: https://reviews.llvm.org/D79495 (cherry picked from commit 57a1c1be53aeea521747dd2f4b0097831341bea5)
* [Driver][CodeGen] Support -fpatchable-function-entry=N,M and ↵Fangrui Song2020-01-241-2/+2
| | | | | | | | | | __attribute__((patchable_function_entry(N,M))) where M>0 Reviewed By: nickdesaulniers Differential Revision: https://reviews.llvm.org/D73072 (cherry picked from commit 69bf40c45fd7f6dfe11b47de42571d8bff5ef94f)
* Revert "PR17164: Change clang's default behavior from ↵Mitch Phillips2020-01-233-23/+15
| | | | | | | | | | | | -flax-vector-conversions=all to -flax-vector-conversions=integer." This patch broke the Sanitizer buildbots. Please see the commit's differential revision for more information (https://reviews.llvm.org/D67678). This reverts commit b72a8c65e4e34779b6bc9e466203f553f5294486. (cherry picked from commit edd4398f4cd33a305afbca76ac4e6590e9337f4d)
* PR17164: Change clang's default behavior from -flax-vector-conversions=all ↵Richard Smith2020-01-173-15/+23
| | | | | | | | | | | | | | | | | | to -flax-vector-conversions=integer. Summary: See proposal on cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2019-April/062030.html Reviewers: SjoerdMeijer, eli.friedman Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67678 (cherry picked from commit b72a8c65e4e34779b6bc9e466203f553f5294486)
* Implement VectorType conditional operator GNU extension.Erich Keane2020-01-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC supports the conditional operator on VectorTypes that acts as a 'select' in C++ mode. This patch implements the support. Types are converted as closely to GCC's behavior as possible, though in a few places consistency with our existing vector type support was preferred. Note that this implementation is different from the OpenCL version in a number of ways, so it unfortunately required a different implementation. First, the SEMA rules and promotion rules are significantly different. Secondly, GCC implements COND[i] != 0 ? LHS[i] : RHS[i] (where i is in the range 0- VectorSize, for each element). In OpenCL, the condition is COND[i] < 0 ? LHS[i]: RHS[i]. In the process of implementing this, it was also required to make the expression COND ? LHS : RHS type dependent if COND is type dependent, since the type is now dependent on the condition. For example: T ? 1 : 2; Is not typically type dependent, since the result can be deduced from the operands. HOWEVER, if T is a VectorType now, it could change this to a 'select' (basically a swizzle with a non-constant mask) with the 1 and 2 being promoted to vectors themselves. While this is a change, it is NOT a standards incompatible change. Based on my (and D. Gregor's, at the time of writing the code) reading of the standard, the expression is supposed to be type dependent if ANY sub-expression is type dependent. Differential Revision: https://reviews.llvm.org/D71463
* Support function attribute patchable_function_entryFangrui Song2020-01-102-0/+26
| | | | | | | | | This feature is generic. Make it applicable for AArch64 and X86 because the backend has only implemented NOP insertion for AArch64 and X86. Reviewed By: nickdesaulniers, aaron.ballman Differential Revision: https://reviews.llvm.org/D72221
* Add support for __declspec(guard(nocf))Andrew Paverd2020-01-101-0/+27
| | | | | | | | | | | | | | | | | | Summary: Avoid using the `nocf_check` attribute with Control Flow Guard. Instead, use a new `"guard_nocf"` function attribute to indicate that checks should not be added on indirect calls within that function. Add support for `__declspec(guard(nocf))` following the same syntax as MSVC. Reviewers: rnk, dmajor, pcc, hans, aaron.ballman Reviewed By: aaron.ballman Subscribers: aaron.ballman, tomrittervg, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72167
* Add builtins for aligning and checking alignment of pointers and integersAlex Richardson2020-01-091-0/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces three new builtins (which work on both pointers and integers) that can be used instead of common bitwise arithmetic: __builtin_align_up(x, alignment), __builtin_align_down(x, alignment) and __builtin_is_aligned(x, alignment). I originally added these builtins to the CHERI fork of LLVM a few years ago to handle the slightly different C semantics that we use for CHERI [1]. Until recently these builtins (or sequences of other builtins) were required to generate correct code. I have since made changes to the default C semantics so that they are no longer strictly necessary (but using them does generate slightly more efficient code). However, based on our experience using them in various projects over the past few years, I believe that adding these builtins to clang would be useful. These builtins have the following benefit over bit-manipulation and casts via uintptr_t: - The named builtins clearly convey the semantics of the operation. While checking alignment using __builtin_is_aligned(x, 16) versus ((x & 15) == 0) is probably not a huge win in readably, I personally find __builtin_align_up(x, N) a lot easier to read than (x+(N-1))&~(N-1). - They preserve the type of the argument (including const qualifiers). When using casts via uintptr_t, it is easy to cast to the wrong type or strip qualifiers such as const. - If the alignment argument is a constant value, clang can check that it is a power-of-two and within the range of the type. Since the semantics of these builtins is well defined compared to arbitrary bit-manipulation, it is possible to add a UBSAN checker that the run-time value is a valid power-of-two. I intend to add this as a follow-up to this change. - The builtins avoids int-to-pointer casts both in C and LLVM IR. In the future (i.e. once most optimizations handle it), we could use the new llvm.ptrmask intrinsic to avoid the ptrtoint instruction that would normally be generated. - They can be used to round up/down to the next aligned value for both integers and pointers without requiring two separate macros. - In many projects the alignment operations are already wrapped in macros (e.g. roundup2 and rounddown2 in FreeBSD), so by replacing the macro implementation with a builtin call, we get improved diagnostics for many call-sites while only having to change a few lines. - Finally, the builtins also emit assume_aligned metadata when used on pointers. This can improve code generation compared to the uintptr_t casts. [1] In our CHERI compiler we have compilation mode where all pointers are implemented as capabilities (essentially unforgeable 128-bit fat pointers). In our original model, casts from uintptr_t (which is a 128-bit capability) to an integer value returned the "offset" of the capability (i.e. the difference between the virtual address and the base of the allocation). This causes problems for cases such as checking the alignment: for example, the expression `if ((uintptr_t)ptr & 63) == 0` is generally used to check if the pointer is aligned to a multiple of 64 bytes. The problem with offsets is that any pointer to the beginning of an allocation will have an offset of zero, so this check always succeeds in that case (even if the address is not correctly aligned). The same issues also exist when aligning up or down. Using the alignment builtins ensures that the address is used instead of the offset. While I have since changed the default C semantics to return the address instead of the offset when casting, this offset compilation mode can still be used by passing a command-line flag. Reviewers: rsmith, aaron.ballman, theraven, fhahn, lebedev.ri, nlopes, aqjune Reviewed By: aaron.ballman, lebedev.ri Differential Revision: https://reviews.llvm.org/D71499
* [ARM,MVE] Fix valid immediate range for vsliq_n.Simon Tatham2020-01-091-0/+93
| | | | | | | | | | | In common with most MVE immediate shift instructions, the left shift takes an immediate in the range [0,n-1], while the right shift takes one in the range [1,n]. I had absent-mindedly made them both the latter. While I'm here, I've added a set of regression tests checking both ends of the immediate range for a representative sample of the immediate shifts.
* [ARM,MVE] Support -ve offsets in gather-load intrinsics.Simon Tatham2020-01-061-8/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The ACLE intrinsics with `gather_base` or `scatter_base` in the name are wrappers on the MVE load/store instructions that take a vector of base addresses and an immediate offset. The immediate offset can be up to 127 times the alignment unit, and it can be positive or negative. At the MC layer, we got that right. But in the Sema error checking for the wrapping intrinsics, the offset was erroneously constrained to be positive. To fix this I've adjusted the `imm_mem7bit` class in the Tablegen that defines the intrinsics. But that causes integer literals like `0xfffffffffffffe04` to appear in the autogenerated calls to `SemaBuiltinConstantArgRange`, which provokes a compiler warning because that's out of the non-overflowing range of an `int64_t`. So I've also tweaked `MveEmitter` to emit that as `-0x1fc` instead. Updated the tests of the Sema checks themselves, and also adjusted a random sample of the CodeGen tests to actually use negative offsets and prove they get all the way through code generation without causing a crash. Reviewers: dmgreen, miyuki, MarkMurrayARM Reviewed By: dmgreen Subscribers: kristof.beyls, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72268
* [Sema] SequenceChecker: Fix handling of operator ||, && and ?:Bruno Ricci2019-12-221-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | The current handling of the operators ||, && and ?: has a number of false positive and false negative. The issues for operator || and && are: 1. We need to add sequencing regions for the LHS and RHS as is done for the comma operator. Not doing so causes false positives in expressions like `((a++, false) || (a++, false))` (from PR39779, see PR22197 for another example). 2. In the current implementation when the evaluation of the LHS fails, the RHS is added to a worklist to be processed later. This results in false negatives in expressions like `(a && a++) + a`. Fix these issues by introducing sequencing regions for the LHS and RHS, and by not deferring the visitation of the RHS. The issues with the ternary operator ?: are similar, with the added twist that we should not warn on expressions like `(x ? y += 1 : y += 2)` since exactly one of the 2nd and 3rd expression is going to be evaluated, but we should still warn on expressions like `(x ? y += 1 : y += 2) = y`. Differential Revision: https://reviews.llvm.org/D57747 Reviewed By: rsmith
* [Wdocumentation] Implement \anchorMark de Wever2019-12-211-0/+7
| | | | Differential revision: https://reviews.llvm.org/D69223
* [attributes][analyzer] Add annotations for handles.Gabor Horvath2019-12-201-0/+22
| | | | | | | These annotations will be used in an upcomming static analyzer check that finds handle leaks, use after releases, and double releases. Differential Revision: https://reviews.llvm.org/D70469
* Add support for the MS qualifiers __ptr32, __ptr64, __sptr, __uptr.Amy Huang2019-12-181-0/+14
| | | | | | | | | | | | | | | | | | | | Summary: This adds parsing of the qualifiers __ptr32, __ptr64, __sptr, and __uptr and lowers them to the corresponding address space pointer for 32-bit and 64-bit pointers. (32/64-bit pointers added in https://reviews.llvm.org/D69639) A large part of this patch is making these pointers ignore the address space when doing things like overloading and casting. https://bugs.llvm.org/show_bug.cgi?id=42359 Reviewers: rnk, rsmith Subscribers: jholewinski, jvesely, nhaehnle, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71039
* Reland [NFC-I] Remove hack for fp-classification builtinsErich Keane2019-12-172-1/+92
| | | | | | | | | | | | | | | | | | The FP-classification builtins (__builtin_isfinite, etc) use variadic packs in the definition file to mean an overload set. Because of that, floats were converted to doubles, which is incorrect. There WAS a patch to remove the cast after the fact. THis patch switches these builtins to just be custom type checking, calls the implicit conversions for the integer members, and makes sure the correct L->R casts are put into place, then does type checking like normal. A future direction (that wouldn't be NFC) would consider making conversions for the floating point parameter legal. Note: The initial patch for this missed that certain systems need to still convert half to float, since they dont' support that type.
* [c++20] Add deprecation warnings for the expression forms deprecated by P1120R0.Richard Smith2019-12-162-2/+2
| | | | | | | | | | | | | | | | | | | This covers: * usual arithmetic conversions (comparisons, arithmetic, conditionals) between different enumeration types * usual arithmetic conversions between enums and floating-point types * comparisons between two operands of array type The deprecation warnings are on-by-default (in C++20 compilations); it seems likely that these forms will become ill-formed in C++23, so warning on them now by default seems wise. For the first two bullets, off-by-default warnings were also added for all the cases where we didn't already have warnings (covering language modes prior to C++20). These warnings are in subgroups of the existing -Wenum-conversion (except that the first case is not warned on if either enumeration type is anonymous, consistent with our existing -Wenum-conversion warnings).
* Revert "[NFC-I] Remove hack for fp-classification builtins"Erich Keane2019-12-162-92/+1
| | | | | | | | | | | This reverts commit b1e542f302c1ed796ad9f703d4d36e010afcb914. The original 'hack' didn't chop out fp-16 to double conversions, so systems that use FP16ConversionIntrinsics end up in IR-CodeGen with an i16 type isntead of a float type (like PPC64-BE). The bots noticed this. Reverting until I figure out how to fix this
* [NFC-I] Remove hack for fp-classification builtinsErich Keane2019-12-162-1/+92
| | | | | | | | | | | | | | | The FP-classification builtins (__builtin_isfinite, etc) use variadic packs in the definition file to mean an overload set. Because of that, floats were converted to doubles, which is incorrect. There WAS a patch to remove the cast after the fact. THis patch switches these builtins to just be custom type checking, calls the implicit conversions for the integer members, and makes sure the correct L->R casts are put into place, then does type checking like normal. A future direction (that wouldn't be NFC) would consider making conversions for the floating point parameter legal.
* [Wdocumentation] Use C2x/C++14 deprecated attributeMark de Wever2019-12-103-14/+59
| | | | | | | | | This replaces the non-standard __attribute__((deprecated)) with the standard [[deprecated]] when compiling in C2x/C++14 mode. Discovered while looking at https://bugs.llvm.org/show_bug.cgi?id=43753 Differential Revision: https://reviews.llvm.org/D71141
* [Wdocumentation] Properly place deprecated attributeMark de Wever2019-12-102-15/+96
| | | | | | | | | | It is now placed before the function: - allows to replace __attribute__((deprecated)) with [[deprecated]]. - required for trailing returns. Fixes bug: https://bugs.llvm.org/show_bug.cgi?id=43753 Differential Revision: https://reviews.llvm.org/D71140
* [Wdocumentation] Use the command marker.Mark de Wever2019-12-101-2/+2
| | | | | | | | | Use the proper marker for -Wdocumentation-deprecated-sync instead of hard-coded the backslash. Discovered while looking at https://bugs.llvm.org/show_bug.cgi?id=43753 Differential Revision: https://reviews.llvm.org/D71139
* Revert "[ARM] Allocatable Global Register Variables for ARM"Carey Williams2019-11-291-20/+0
| | | | This reverts commit 2d739f98d8a53e38bf9faa88cdb6b0c2a363fb77.
* [mips] Check that features required by built-ins are enabledSimon Atanasyan2019-11-291-0/+37
| | | | | | | | | | | | Now Clang does not check that features required by built-in functions are enabled. That causes errors in the backend reported in PR44018. This patch fixes this bug by checking that required features are enabled. This should fix PR44018. Differential Revision: https://reviews.llvm.org/D70808
* [LifetimeAnalysis] Fix PR44150Gabor Horvath2019-11-271-0/+5
| | | | | | | | References need somewhat special treatment. While copying a gsl::Pointer will propagate the points-to set, creating an object from a reference often behaves more like a dereference operation. Differential Revision: https://reviews.llvm.org/D70755
* Workaround for EvalInfo ctor for MSVC 2017Yaxun (Sam) Liu2019-11-261-0/+9
| | | | | | | | | | | | Current EvalInfo ctor causes EnableNewConstInterp to be true even though it is supposed to be false on MSVC 2017. This is because a virtual function getLangOpts() is called in member initializer lists, whereas on MSVC member ctors are called before function virtual function pointers are initialized. This patch fixes that. Differential Revision: https://reviews.llvm.org/D70729
* [Diagnostics] Warn for comparison with string literals expanded from macro ↵Dávid Bolvanský2019-11-242-1/+30
| | | | | | | | | | | | | | | | | | (PR44064) Summary: As noted in PR, we have a poor test coverage for this warning. I think macro support was just overlooked. GCC warns in these cases. Clang missed a real bug in the code I am working with, GCC caught it. Reviewers: aaron.ballman Reviewed By: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70624
* Revert "[Sema] Use the canonical type in function isVector"Akira Hatanaka2019-11-221-7/+0
| | | | | This reverts commit a6150b48cea00ab31e9335cc73770327acc4cb3a. The commit broke a few neon CodeGen tests.
* [Sema] Use the canonical type in function isVectorAkira Hatanaka2019-11-221-0/+7
| | | | | | | This fixes an assertion in Sema::CreateBuiltinBinOp that fails when one of the vector operand's element type is a typedef of __fp16. rdar://problem/55983556
* Fix typo to separate "-x" from warning flag.Bill Wendling2019-11-221-1/+1
|
* Don't report "main" as missing a prototype in freestanding modeBill Wendling2019-11-221-0/+6
| | | | | | | | | | | | | | | | | Summary: A user may want to use freestanding mode with the standard "main" entry point. It's not useful to warn about a missing prototype as it's not typical to have a prototype for "main". Reviewers: efriedma, aaron.ballman Reviewed By: aaron.ballman Subscribers: aaron.ballman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70588
* Atomics: support min/max orthogonallyTim Northover2019-11-211-2/+30
| | | | | | | | | | | | We seem to have been gradually growing support for atomic min/max operations (exposing longstanding IR atomicrmw instructions). But until now there have been gaps in the expected intrinsics. This adds support for the C11-style intrinsics (i.e. taking _Atomic, rather than individually blessed by C11 standard), and the variants that return the new value instead of the original one. That way, people won't be misled by trying one form and it not working, and the front-end is more friendly to people using _Atomic types, as we recommend.
* [Sema] Add a 'Semantic' parameter to Expr::isKnownToHaveBooleanValueErik Pilkington2019-11-201-0/+11
| | | | | | | | | Some clients of this function want to know about any expression that is known to produce a 0/1 value, and others care about expressions that are semantically boolean. This fixes a -Wswitch-bool regression I introduced in 8bfb353bb33c, pointed out by Chris Hamilton!
* [AST] Attach comment in `/** doc */ typedef struct A {} B` to B as well as A.Sam McCall2019-11-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: Semantically they're the same thing, and it's important when the underlying struct is anonymous. There doesn't seem to be a problem attaching the same comment to multiple things as it already happens with `/** doc */ int a, b;` This affects an Index test but the results look better (name present, USR points to the typedef). Fixes https://github.com/clangd/clangd/issues/189 Reviewers: kadircet, lh123 Subscribers: ilya-biryukov, jkorous, arphaman, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70203
* [ARM] Allocatable Global Register Variables for ARMAnna Welker2019-11-181-0/+20
| | | | | | | | | | | | Provides support for using r6-r11 as globally scoped register variables. This requires a -ffixed-rN flag in order to reserve rN against general allocation. If for a given GRV declaration the corresponding flag is not found, or the the register in question is the target's FP, we fail with a diagnostic. Differential Revision: https://reviews.llvm.org/D68862
* Implement target(branch-protection) attribute for AArch64Momchil Velikov2019-11-152-1/+24
| | | | | | | | | This patch implements `__attribute__((target("branch-protection=...")))` in a manner, compatible with the analogous GCC feature: https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/AArch64-Function-Attributes.html#AArch64-Function-Attributes Differential Revision: https://reviews.llvm.org/D68711
* [ARM,MVE] Add intrinsics for vector get/set lane.Simon Tatham2019-11-151-1/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the `vgetq_lane` and `vsetq_lane` families, to copy between a scalar and a specified lane of a vector. One of the new `vgetq_lane` intrinsics returns a `float16_t`, which causes a compile error if `%clang_cc1` doesn't get the option `-fallow-half-arguments-and-returns`. The driver passes that option to cc1 already, but I've had to edit all the explicit cc1 command lines in the existing MVE intrinsics tests. A couple of fixes are included for the code I wrote up front in MveEmitter to support lane-index immediates (and which nothing has tested until now): the type was wrong (`uint32_t` instead of `int`) and the range was off by one. I've also added a method of bypassing the default promotion to `i32` that is done by the MveEmitter code generation: it's sensible to promote short scalars like `i16` to `i32` if they're going to be passed to custom IR intrinsics representing a machine instruction operating on GPRs, but not if they're going to be passed to standard IR operations like `insertelement` which expect the exact type. Reviewers: ostannard, MarkMurrayARM, dmgreen Reviewed By: dmgreen Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70188
* [BPF] Restrict preserve_access_index attribute to C onlyYonghong Song2019-11-141-0/+9
| | | | | | | | | | | | This patch is a follow-up for commit 4e2ce228ae79 [BPF] Add preserve_access_index attribute for record definition to restrict attribute for C only. A new test case is added to check for this restriction. Additional code polishing is done based on Aaron Ballman's suggestion in https://reviews.llvm.org/D69759/new/. Differential Revision: https://reviews.llvm.org/D70257
* [BPF] Add preserve_access_index attribute for record definitionYonghong Song2019-11-131-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a resubmission for the previous reverted commit 943436040121 with the same subject. This commit fixed the segfault issue and addressed additional review comments. This patch introduced a new bpf specific attribute which can be added to struct or union definition. For example, struct s { ... } __attribute__((preserve_access_index)); union u { ... } __attribute__((preserve_access_index)); The goal is to simplify user codes for cases where preserve access index happens for certain struct/union, so user does not need to use clang __builtin_preserve_access_index for every members. The attribute has no effect if -g is not specified. When the attribute is specified and -g is specified, any member access defined by that structure or union, including array subscript access and inner records, will be preserved through __builtin_preserve_{array,struct,union}_access_index() IR intrinsics, which will enable relocation generation in bpf backend. The following is an example to illustrate the usage: -bash-4.4$ cat t.c #define __reloc__ __attribute__((preserve_access_index)) struct s1 { int c; } __reloc__; struct s2 { union { struct s1 b[3]; }; } __reloc__; struct s3 { struct s2 a; } __reloc__; int test(struct s3 *arg) { return arg->a.b[2].c; } -bash-4.4$ clang -target bpf -g -S -O2 t.c A relocation with access string "0:0:0:0:2:0" will be generated representing access offset of arg->a.b[2].c. forward declaration with attribute is also handled properly such that the attribute is copied and populated in real record definition. Differential Revision: https://reviews.llvm.org/D69759
* Add -Wtautological-compare to -WallWeverything2019-11-122-0/+2
| | | | | | | | Some warnings in -Wtautological-compare subgroups are DefaultIgnore. Adding this group to -Wmost, which is part of -Wall, will aid in their discoverability. Differential Revision: https://reviews.llvm.org/D69292
* AArch64: add arm64_32 support to Clang.Tim Northover2019-11-122-0/+3
|
* [Diagnostics] Try to improve warning message for -Wreturn-typeDávid Bolvanský2019-11-094-25/+25
| | | | | | | | | | | | | | Summary: I agree with https://easyaspi314.github.io/gcc-vs-clang.html?fbclid=IwAR1VA0qxiWVUusOQUv5z7JESS7ZpeJy-UqAI5mnJscofGLqXcqeErIUB2gU, current warning message is not very good. We should try to improve it.. Reviewers: rsmith, aaron.ballman, easyaspi314 Reviewed By: aaron.ballman Subscribers: arphaman, Quuxplusone, mehdi_amini, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69762
* Revert "[BPF] Add preserve_access_index attribute for record definition"Yonghong Song2019-11-091-48/+0
| | | | | | This reverts commit 4a5aa1a7bf8b1714b817ede8e09cd28c0784228a. There are some other test failures. Investigate them first.
* [BPF] Add preserve_access_index attribute for record definitionYonghong Song2019-11-091-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduced a new bpf specific attribute which can be added to struct or union definition. For example, struct s { ... } __attribute__((preserve_access_index)); union u { ... } __attribute__((preserve_access_index)); The goal is to simplify user codes for cases where preserve access index happens for certain struct/union, so user does not need to use clang __builtin_preserve_access_index for every members. The attribute has no effect if -g is not specified. When the attribute is specified and -g is specified, any member access defined by that structure or union, including array subscript access and inner records, will be preserved through __builtin_preserve_{array,struct,union}_access_index() IR intrinsics, which will enable relocation generation in bpf backend. The following is an example to illustrate the usage: -bash-4.4$ cat t.c #define __reloc__ __attribute__((preserve_access_index)) struct s1 { int c; } __reloc__; struct s2 { union { struct s1 b[3]; }; } __reloc__; struct s3 { struct s2 a; } __reloc__; int test(struct s3 *arg) { return arg->a.b[2].c; } -bash-4.4$ clang -target bpf -g -S -O2 t.c A relocation with access string "0:0:0:0:2:0" will be generated representing access offset of arg->a.b[2].c. forward declaration with attribute is also handled properly such that the attribute is copied and populated in real record definition. Differential Revision: https://reviews.llvm.org/D69759
* [SEH] Defer checking filter expression types until instantiatonReid Kleckner2019-11-071-1/+1
| | | | | | | | | | | While here, wordsmith the error a bit. Now clang says: error: filter expression has non-integral type 'Foo' Fixes PR43779 Reviewers: amccarth Differential Revision: https://reviews.llvm.org/D69969
* [Diagnostics] Teach -Wnull-dereference about address_space attributeDávid Bolvanský2019-11-071-5/+15
| | | | | | | | | | | | | | | | | | | | | | Summary: Clang should not warn for: > test.c:2:12: warning: indirection of non-volatile null pointer will be deleted, > not trap [-Wnull-dereference] > return *(int __attribute__((address_space(256))) *) 0; > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Solves PR42292. Reviewers: aaron.ballman, rsmith Reviewed By: aaron.ballman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69664
* [ARM,MVE] Add intrinsics for gather/scatter load/stores.Simon Tatham2019-11-061-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds two new families of intrinsics, both of which are memory accesses taking a vector of locations to load from / store to. The vldrq_gather_base / vstrq_scatter_base intrinsics take a vector of base addresses, and an immediate offset to be added consistently to each one. vldrq_gather_offset / vstrq_scatter_offset take a scalar base address, and a vector of offsets to add to it. The 'shifted_offset' variants also multiply each offset by the element size type, so that the vector is effectively of array indices. At the IR level, these operations are represented by a single set of four IR intrinsics: {gather,scatter} × {base,offset}. The other details (signed/unsigned, shift, and memory element size as opposed to vector element size) are all specified by IR intrinsic polymorphism and immediate operands, because that made the selection job easier than making a huge family of similarly named intrinsics. I considered using the standard IR representations such as llvm.masked.gather, but they're not a good fit. In order to use llvm.masked.gather to represent a gather_offset load with element size smaller than a pointer, you'd have to expand the <8 x i16> vector of offsets into an <8 x i16*> vector of pointers, which would be split up during legalization, so you'd spend most of your time undoing the mess it had made. Also, ISel support for llvm.masked.gather would be easy enough in a trivial way (you can expand it into a gather-base load with a zero immediate offset), but instruction-selecting lots of fiddly idioms back into all the _other_ MVE load instructions would be much more work. So I think dedicated IR intrinsics are the more sensible approach, at least for the moment. On the clang tablegen side, I've added two new features to the Tablegen source accepted by MveEmitter: a 'CopyKind' type node for defining a type that varies with the parameter type (it lets you ask for an unsigned integer type of the same width as the parameter), and an 'unsignedflag' value node for passing an immediate IR operand which is 0 for a signed integer type or 1 for an unsigned one. That lets me write each kind of intrinsic just once and get all its subtypes and immediate arguments generated automatically. Also I've tweaked the handling of pointer-typed values in the code generation part of MveEmitter: they're generated as Address rather than Value (i.e. including an alignment) so that they can be given to the ordinary IR load and store operations, but I'd omitted the code to convert them back to Value when they're going to be used as an argument to an IR intrinsic. On the MC side, I've enhanced MVEVectorVTInfo so that it can tell you not only the full assembly-language suffix for a given vector type (like 's32' or 'u16') but also the numeric-only one used by store instructions (just '32' or '16'). Reviewers: dmgreen Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69791
* Fix missing memcpy builtin on ppc64beGuillaume Chatelet2019-10-291-0/+1
| | | | See D68028
* [clang] Add no_builtin attributeGuillaume Chatelet2019-10-291-0/+51
| | | | | | | | | | | | | | | | Summary: This is a follow up on https://reviews.llvm.org/D61634 This patch is simpler and only adds the no_builtin attribute. Reviewers: tejohnson, courbet, theraven, t.p.northover, jdoerfert Subscribers: mgrang, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68028 This is a re-submit after it got reverted in https://reviews.llvm.org/rGbd8791610948 since the breakage doesn't seem to come from this patch.
* Revert "[clang] Add no_builtin attribute"Vlad Tsyrklevich2019-10-281-51/+0
| | | | | This reverts commit bd87916109483d33455cbf20da2309197b983cdd. It was causing ASan/MSan failures on the sanitizer buildbots.
* [clang] Add no_builtin attributeGuillaume Chatelet2019-10-281-0/+51
| | | | | | | | | | | | | | Summary: This is a follow up on https://reviews.llvm.org/D61634 This patch is simpler and only adds the no_builtin attribute. Reviewers: tejohnson, courbet, theraven, t.p.northover, jdoerfert Subscribers: mgrang, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68028
OpenPOWER on IntegriCloud