summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [CMake] Support running libc++abi tests in CrossWinToARMLinux cache fileSergej Jaskiewicz2020-01-101-0/+3
| | | | | | | | | | | | | | | | | Summary: Now that D71894 has landed, we're able to run libc++abi tests remotely. For that we can use the same CMake command as before. The tests can be run using `ninja check-cxxabi`. Reviewers: andreil99, vvereschaka, aorlov Reviewed By: vvereschaka, aorlov Subscribers: mgorny, kristof.beyls, ldionne, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72459
* [libcxx] Force-cache LIBCXX_CXX_ABI_LIBRARY_PATHSergej Jaskiewicz2020-01-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The `LIBCXX_CXX_ABI_LIBRARY_PATH` CMake variable is cached once in libcxx/cmake/Modules/HandleLibCXXABI.cmake in the `setup_abi_lib` macro, and then cached again in libcxx/test/CMakeLists.txt. There, if it is not set to a value, it is by default set to `LIBCXX_LIBRARY_DIR`. However, this new value is not actually cached, because the old (empty) value has been already cached. Use the `FORCE` CMake flag so that it is saved to the cache. This should not break anything, because the code changed here previously had no effect, when it should have. Reviewers: jroelofs, bcraig, ldionne, EricWF, mclow.lists, vvereschaka, eastig Reviewed By: vvereschaka Subscribers: mgorny, christof, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D69169
* Follow up of 67bf9a6154d4b82c, minor fix in test case, removed duplicate optionSjoerd Meijer2020-01-101-1/+1
|
* [SVEV] Recognise hardware-loop intrinsic loop.decrement.regSjoerd Meijer2020-01-104-0/+108
| | | | | | | | | | | | | | | Teach SCEV about the @loop.decrement.reg intrinsic, which has exactly the same semantics as a sub expression. This allows us to query hardware-loops, which contain this @loop.decrement.reg intrinsic, so that we can calculate iteration counts, exit values, etc. of hardwareloops. This "int_loop_decrement_reg" intrinsic is defined as "IntrNoDuplicate". Thus, while hardware-loops and tripcounts now become analysable by SCEV, this prevents the usual loop transformations from applying transformations on hardware-loops, which is what we want at this point, for which I have added test cases for loopunrolling and IndVarSimplify and LFTR. Differential Revision: https://reviews.llvm.org/D71563
* Fix several issues with compiler extensionsserge-sans-paille2020-01-104-36/+35
| | | | | | | | | | | | | | | | - Update documentation now that the move to monorepo has been made - Do not tie compiler extension testing to LLVM_BUILD_EXAMPLES - No need to specify LLVM libraries for plugins - Add NO_MODULE option to match Polly specific requirements (i.e. building the module *and* linking it statically) - Issue a warning when building the compiler extension with LLVM_BYE_LINK_INTO_TOOLS=ON, as it modifies the behavior of clang, which only makes sense for testing purpose. Still mark llvm/test/Feature/load_extension.ll as XFAIL because of a ManagedStatic dependency that's going to be fixed in a seperate commit. Differential Revision: https://reviews.llvm.org/D72327
* [clangd] Fix markdown rendering in VSCodeKadir Cetinkaya2020-01-102-11/+12
| | | | | | | | | | | | | | | Summary: Eventough it is OK to have a new line without any preceding spaces in some markdown specifications, VSCode requires two spaces before a new line to break a line inside a paragraph. Reviewers: sammccall, ilya-biryukov Subscribers: MaskRay, jkorous, arphaman, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72462
* [clangd] Improve type printing in hoverKadir Cetinkaya2020-01-102-15/+36
| | | | | | | | | | | | | | | | | | Summary: Do not include tag keywords when printing types for symbol names, as it will come from SymbolKind. Also suppress them while printing definitions to prevent them occuring in template arguments. Make use of `getAsString`, instead of `print` in all places to have a consistent style across the file. Reviewers: sammccall Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72450
* [NFC] [PowerPC] Add isPredicable for basic instrsQiu Chaofan2020-01-104-34/+21
| | | | | | | | | PowerPC uses a dedicated method to check if the machine instr is predicable by opcode. However, there's a bit `isPredicable` in instr definition. This patch removes the method and set the bit only to opcodes referenced in it. Differential Revision: https://reviews.llvm.org/D71921
* Allow system header to provide their own implementation of some builtinserge-sans-paille2020-01-106-1/+58
| | | | | | | | | | | | | | | | | | If a system header provides an (inline) implementation of some of their function, clang still matches on the function name and generate the appropriate llvm builtin, e.g. memcpy. This behavior is in line with glibc recommendation « users may not provide their own version of symbols » but doesn't account for the fact that glibc itself can provide inline version of some functions. It is the case for the memcpy function when -D_FORTIFY_SOURCE=1 is on. In that case an inline version of memcpy calls __memcpy_chk, a function that performs extra runtime checks. Clang currently ignores the inline version and thus provides no runtime check. This code fixes the issue by detecting functions whose name is a builtin name but also have an inline implementation. Differential Revision: https://reviews.llvm.org/D71082
* Restore order in clang-tidy section of release notesHans Wennborg2020-01-101-49/+61
| | | | | | | | Major changes are introduction of subsubsections to prevent people putting new entries in wrong places. I also polished line length and highlighting. Patch by Eugene Zelenko!
* [LV] VPValues for memory operation pointers (NFCI)Gil Rapaport2020-01-105-104/+141
| | | | | | | | | | | | Memory instruction widening recipes use the pointer operand of their load/store ingredient for generating the needed GEPs, making it difficult to feed these recipes with pointers based on other ingredients or none at all. This patch modifies these recipes to use a VPValue for the pointer instead, in order to reduce ingredient def-use usage by ILV as a step towards full VPlan-based def-use relations. The recipes are constructed with VPValues bound to these ingredients, maintaining current behavior. Differential revision: https://reviews.llvm.org/D70865
* [Syntax] Update comment, remove stale FIXME. NFCIlya Biryukov2020-01-101-3/+3
|
* clang-tidy doc - remove the widthsSylvestre Ledru2020-01-101-2/+0
|
* [xray] Remove cl::sub from alias optionsShoaib Meenai2020-01-096-78/+41
| | | | | | | | | | | | | | | | | | | Currently running the xray tools generates a number of errors: $ ./bin/llvm-xray : for the -k option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! : for the -d option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! : for the -o option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! : for the -f option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! : for the -s option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! : for the -r option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! : for the -p option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! : for the -m option: cl::alias must not have cl::sub(), aliased option's cl::sub() will be used! <snip> Patch by Ryan Mansfield. Differential Revision: https://reviews.llvm.org/D69386
* [ThinLTO] Pass CodeGenOpts like UnrollLoops/VectorizeLoop/VectorizeSLPWei Mi2020-01-0917-1/+263
| | | | | | | | | | | | | down to pass builder in ltobackend. Currently CodeGenOpts like UnrollLoops/VectorizeLoop/VectorizeSLP in clang are not passed down to pass builder in ltobackend when new pass manager is used. This is inconsistent with the behavior when new pass manager is used and thinlto is not used. Such inconsistency causes slp vectorization pass not being enabled in ltobackend for O3 + thinlto right now. This patch fixes that. Differential Revision: https://reviews.llvm.org/D72386
* fix another typo to cycle botsNico Weber2020-01-091-1/+1
|
* fix a few typos to cycle the botsNico Weber2020-01-094-8/+8
|
* [NFC] Style cleanupShengchen Kan2020-01-101-9/+10
|
* CWG2352: Allow qualification conversions during reference binding.Richard Smith2020-01-0912-154/+280
| | | | | | | | | | | | | | | | | | | | | | The language wording change forgot to update overload resolution to rank implicit conversion sequences based on qualification conversions in reference bindings. The anticipated resolution for that oversight is implemented here -- we order candidates based on qualification conversion, not only on top-level cv-qualifiers, including ranking reference bindings against non-reference bindings if they differ in non-top-level qualification conversions. For OpenCL/C++, this allows reference binding between pointers with differing (nested) address spaces. This makes the behavior of reference binding consistent with that of implicit pointer conversions, as is the purpose of this change, but that pre-existing behavior for pointer conversions is itself probably not correct. In any case, it's now consistently the same behavior and implemented in only one place. This reinstates commit de21704ba96fa80d3e9402f12c6505917a3885f4, reverted in commit d8018233d1ea4234de68d5b4593abd773db79484, with workarounds for some overload resolution ordering problems introduced by CWG2352.
* Relax opcode checks in test for G_READCYCLECOUNTER to check for only a ↵Douglas Yung2020-01-091-1/+1
| | | | number instead of a specific number.
* AMDGPU/GlobalISel: Select G_EXTRACT_VECTOR_ELTMatt Arsenault2020-01-097-10/+2188
| | | | | Doesn't try to do the fold into the base register of an add of a constant in the index like the DAG path does.
* AMDGPU/GlobalISel: Fix G_EXTRACT_VECTOR_ELT mapping for s-v caseMatt Arsenault2020-01-093-26/+103
| | | | | | If an SGPR vector is indexed with a VGPR, the actual indexing will be done on the SGPR and produce an SGPR. A copy needs to be inserted inside the waterwall loop to the VGPR result.
* [ELF] Fix includeInDynsym() when an undefined weak is merged with a lazy ↵Fangrui Song2020-01-092-1/+8
| | | | | | | | | | | | definition An undefined weak does not fetch the lazy definition. A lazy weak symbol should be considered undefined, and thus preemptible if .dynsym exists. D71795 is not quite an NFC. It errors on an R_X86_64_PLT32 referencing an undefined weak symbol. isPreemptible is false (incorrect) => R_PLT_PC is optimized to R_PC => in isStaticLinkTimeConstant, an error is emitted when an R_PC is applied on an undefined weak (considered absolute).
* When reading Aux file in chunks, read consecutive byte rangesJason Molenda2020-01-092-1/+161
| | | | | | | | | | | | | | | | | | | | | | | qemu has a very small maximum packet size (4096) and it actually only uses half of that buffer for some implementation reason, so when lldb asks for the register target definitions, the x86_64 definition is larger than 4096/2 and we need to fetch it in two parts. This patch and test is fixing a bug in GDBRemoteCommunicationClient::ReadExtFeature when reading a target file in multiple parts. lldb was assuming that it would always get back the maximum packet size response (4096) instead of using the actual size received and asking for the next group of bytes. We now have two tests in gdb_remote_client for unique features of qemu - TestNestedRegDefinitions.py would test the ability of lldb to follow multiple levels of xml includes; I opted to create a separate TestRegDefinitionInParts.py test to test this wrinkle in qemu's gdb remote serial protocol stub implementation. Instead of combining both tests into a single test file. <rdar://problem/49537922>
* [AMDGPU] Fix bundle schedulingStanislav Mekhanoshin2020-01-0919-31/+92
| | | | | | | Bundles coming to scheduler considered free, i.e. zero latency. Fixed. Differential Revision: https://reviews.llvm.org/D72487
* [lldb] Remove spurious fileJonas Devlieghere2020-01-091-51/+0
|
* AVR: Update for getRegisterByName changeMatt Arsenault2020-01-092-3/+3
|
* When diagnosing the lack of a viable conversion function, also listRichard Smith2020-01-0921-172/+204
| | | | | | | | | | | | | | explicit functions that are not candidates. It's not always obvious that the reason a conversion was not possible is because the function you wanted to call is 'explicit', so explicitly say if that's the case. It would be nice to rank the explicit candidates higher in the diagnostic if an implicit conversion sequence exists for their arguments, but unfortunately we can't determine that without potentially triggering non-immediate-context errors that we're not permitted to produce.
* [mlir] Use getDenseElementBitwidth instead of Type::getElementTypeBitWidth.River Riddle2020-01-092-1/+12
| | | | | | | | Summary: Some data values have a different storage width than the corresponding MLIR type, e.g. bfloat is currently stored as a double. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D72478
* [lldb/Lua] Add lua typemaps for INOUT paramsJonas Devlieghere2020-01-092-0/+2
|
* TableGen/GlobalISel: Fix pattern matching of immarg literalsMatt Arsenault2020-01-098-30/+140
| | | | | | | | | | | | | | | | | For arguments that are not expected to be materialized with G_CONSTANT, this was emitting predicates which could never match. It was first adding a meaningless LLT check, which would always fail due to the operand not being a register. Infer the cases where a literal should check for an immediate operand, instead of a register This avoids needing to invent a special way of representing timm literal values. Also handle immediate arguments in GIM_CheckLiteralInt. The comments stated it handled isImm() and isCImm(), but that wasn't really true. This unblocks work on the selection of all of the complicated AMDGPU intrinsics in future commits.
* TableGen/GlobalISel: Add way for SDNodeXForm to work on timmMatt Arsenault2020-01-0914-38/+234
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current implementation assumes there is an instruction associated with the transform, but this is not the case for timm/TargetConstant/immarg values. These transforms should directly operate on a specific MachineOperand in the source instruction. TableGen would assert if you attempted to define an equivalent GISDNodeXFormEquiv using timm when it failed to find the instruction matcher. Specially recognize SDNodeXForms on timm, and pass the operand index to the render function. Ideally this would be a separate render function type that looks like void renderFoo(MachineInstrBuilder, const MachineOperand&), but this proved to be somewhat mechanically painful. Add an optional operand index which will only be passed if the transform should only look at the one source operand. Theoretically it would also be possible to only ever pass the MachineOperand, and the existing renderers would check the parent. I think that would be somewhat ugly for the standard usage which may want to inspect other operands, and I also think MachineOperand should eventually not carry a pointer to the parent instruction. Use it in one sample pattern. This isn't a great example, since the transform exists to satisfy DAG type constraints. This could also be avoided by just changing the MachineInstr's arbitrary choice of operand type from i16 to i32. Other patterns have nontrivial uses, but this serves as the simplest example. One flaw this still has is if you try to use an SDNodeXForm defined for imm, but the source pattern uses timm, you still see the "Failed to lookup instruction" assert. However, there is now a way to avoid it.
* GlobalISel: Handle llvm.read_registerMatt Arsenault2020-01-097-2/+59
| | | | | Compared to the attempt in bdcc6d3d2638b3a2c99ab3b9bfaa9c02e584993a, this uses intermediate generic instructions.
* DAG: Don't use unchecked dyn_castMatt Arsenault2020-01-091-4/+4
|
* GlobalISel: Fix else after returnMatt Arsenault2020-01-091-3/+9
|
* CodeGen: Use LLT instead of EVT in getRegisterByNameMatt Arsenault2020-01-0922-27/+32
| | | | | | Only PPC seems to be using it, and only checks some simple cases and doesn't distinguish between FP. Just switch to using LLT to simplify use from GlobalISel.
* [AArch64][GlobalISel] Implement selection of <2 x float> vector splat.Amara Emerson2020-01-095-13/+107
| | | | | | Also requires making G_IMPLICIT_DEF of v2s32 legal. Differential Revision: https://reviews.llvm.org/D72422
* [mlir] add a missing dependency for Linalg conversionEric Schweitz2020-01-091-0/+1
| | | | | | | We were seeing some occasional build failures that would come and go. It appeared to be this missing dependence. Differential Revision: https://reviews.llvm.org/D72419
* [mlir] mlir-cpu-runner test's cblas_interface should export functions on WindowsKern Handa2020-01-095-7/+66
| | | | | | | | | | | | This change fixes the build on Windows, so that cblas_interface.dll exports functions correctly and an implib is created and installed correctly. Currently, LLVM cannot be consumed on Windows after it has been installed in a location because cblas_interface.lib is not created/installed, thus failing the import check in `LLVMExports.cmake`. Differential Revision: https://reviews.llvm.org/D72384
* Add builtins for aligning and checking alignment of pointers and integersAlex Richardson2020-01-0913-11/+1025
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add gdb pretty printer for MutableArrayRef, remove ConstArrayRef.Christian Sigg2020-01-091-1/+1
| | | | | | | | | | | | Reviewers: dblaikie Reviewed By: dblaikie Subscribers: merge_guards_bot, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72136
* GlobalISel: Move getLLTForMVT/getMVTForLLTMatt Arsenault2020-01-094-22/+26
| | | | | | As an intermediate step, some TLI functions can be converted to using LLT instead of MVT. Move this somewhere out of GlobalISel so DAG functions can use these.
* TableGen/GlobalISel: Address fixmeMatt Arsenault2020-01-093-6/+14
| | | | Don't call computeAvailableFunctionFeatures for every instruction.
* GlobalISel: Don't assert on MoreElements creating vectorsMatt Arsenault2020-01-091-5/+7
| | | | | | | If the original type was a scalar, it should be valid to add elements to turn it into a vector. Tests included with following legalization change.
* AMDGPU/GlobalISel: Fix argument lowering for vectors of pointersMatt Arsenault2020-01-092-16/+134
| | | | | | | When these arguments are broken down by the EVT based callbacks, the pointer information is lost. Hack around this by coercing the register types to be the expected pointer element type when building the remerge operations.
* AMDGPU/GlobalISel: Widen 16-bit shift amount sourcesMatt Arsenault2020-01-094-81/+96
| | | | | | This should be legal, but will require future selection work. 16-bit shift amounts were already removed from being legal, but this didn't adjust the transformation rules.
* phab doc: Replace or remove references to svnSylvestre Ledru2020-01-091-7/+6
|
* phab doc: also document 'arc land'Sylvestre Ledru2020-01-091-0/+6
|
* phab doc: remove the svn sectionSylvestre Ledru2020-01-091-14/+0
|
* [clangd] Handle DeducedTemplateSpecializationType in TargetFinderNathan Ridge2020-01-092-1/+40
| | | | | | | | | | | | | | Summary: This is a workaround for https://bugs.llvm.org/show_bug.cgi?id=42914. Once that is fixed, the handling in VisitDeducedTyped() should be sufficient. Fixes https://github.com/clangd/clangd/issues/242 Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72119
OpenPOWER on IntegriCloud