- Sep 17, 2021
-
-
thomasraoux authored
Differential Revision: https://reviews.llvm.org/D107856
-
Vy Nguyen authored
[lld-macho] Ignore local personality symbols if non-local with the same name exisst, to avoid "too many personalities" error. Sometimes people intentionally re-define a dylib personlity symbol as a local defined symbol as a workaround to a ld -r bug. As a result, we could see "too many personalities" to encode. This patch tries to handle this case by ignoring the local symbols entirely. Differential Revision: https://reviews.llvm.org/D107533
-
Shilei Tian authored
-
peter klausler authored
INT, NINT, FLOOR, and CEILING were failing to report overflow as an error while folding operations with constant operands. Differential Revision: https://reviews.llvm.org/D109922
-
AndreyChurbanov authored
-
AndreyChurbanov authored
The third-party ittnotify sources updated from https://github.com/intel/ittapi. Changes applied: - llvm license aded to all files; initial BSD license saved in LICENSE.txt; - clang-formatted; - renamed *.c to *.cpp, similar to what we did with all our sources; - added #include "kmp_config.h" with definition of INTEL_ITTNOTIFY_PREFIX macro into ittnotify_static.cpp. Differential Revision: https://reviews.llvm.org/D109333
-
peter klausler authored
The intrinsic inquiry functions SIZE and UBOUND -- but not LBOUND -- require a DIM= argument if their first argument is an assumed-size array. The intrinsic SHAPE must not be used with an assumed-size array. Differential Revision: https://reviews.llvm.org/D109912
-
Kazu Hirata authored
-
Roman Lebedev authored
[X86] Improve `matchBinaryShuffle()`'s `BLEND` lowering with per-element all-zero/all-ones knowledge We can use `OR` instead of `BLEND` if either the element we are not picking is zero (or masked away); or the element we are picking overwhelms (e.g. it's all-ones) whatever the element we are not picking: https://alive2.llvm.org/ce/z/RKejao Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D109726
-
Nico Weber authored
-
peter klausler authored
Silence a bogus error message about an out-of-range DIM= argument when the argument is assumed-rank. (More generally, don't pretend to be able to discern a shape of known rank for an assumed-rank object.) Differential Revision: https://reviews.llvm.org/D109915
-
Sanjay Patel authored
Mostly cosmetic diffs, but the use of m_APInt matches splat constants.
-
Sanjay Patel authored
-
Tobias Gysi authored
Add the addTileLoopIvsToIndexOpResults method to shift the IndexOp results after tiling. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D109761
-
peter klausler authored
Validation of the optional generic-spec on an END INTERFACE statement was missing many possible error cases; reimplement it. Differential Revision: https://reviews.llvm.org/D109910
-
Thomas Preud'homme authored
Re-add -fexperimental-new-pass-manager to Clang::CodeGen/pgo-sample-thinlto-summary.c for the test to work on builds that still default to the old pass manager. Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D109956
-
Matt Morehouse authored
Reviewed By: xiangzhangllvm Differential Revision: https://reviews.llvm.org/D109790
-
PeixinQiao authored
This patch implements the following semantic checks according to OpenMP Version 5.1 Ordered construct restriction: ``` At most one threads clause can appear on an ordered construct; At most one simd clause can appear on an ordered construct; At most one depend(source) clause can appear on an ordered construct; Either depend(sink:vec) clauses or depend(source) clauses may appear on an ordered construct, but not both. ``` This patch also implements the following semantic checks according to the syntax and descriptions in OpenMP Version 5.1 Ordered construct: ``` The dependence types of sink or source are only allowed on an ordered construct. The depend(*) clauses are not allowed when ordered construct is a block construct with an ordered region. The threads or simd clauses are not allowed when the ordered construct is a standalone construct with no ordered region. ``` Co-authored-by:
Sameeran Joshi <sameeranjayant.joshi@amd.com> Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D108512
-
Dávid Bolvanský authored
-
Erich Keane authored
Seemingly, names in anonymous namespaces are ALWAYS given the unique internal linkage name on windows, and I was not aware of this when I put the names in my test! Replaced them with a wildcard.
-
Justas Janickas authored
Adds support for a feature macro `__opencl_c_read_write_images` in C++ for OpenCL 2021 enabling a respective optional core feature from OpenCL 3.0. This change aims to achieve compatibility between C++ for OpenCL 2021 and OpenCL 3.0. Differential Revision: https://reviews.llvm.org/D109307
-
Simon Pilgrim authored
Avoid unnecessary copies, reported by MSVC static analyzer.
-
Simon Pilgrim authored
Avoid unnecessary copies, reported by MSVC static analyzer.
-
Simon Pilgrim authored
Avoid unnecessary copies, reported by MSVC static analyzer.
-
Simon Pilgrim authored
Avoid unnecessary copies, reported by MSVC static analyzer.
-
Erich Keane authored
We previously made all multiversioning resolvers/ifuncs have weak ODR linkage in IR, since we NEED to emit the whole resolver every time we see a call, but it is not necessarily the place where all the definitions live. HOWEVER, when doing so, we neglected the case where the versions have internal linkage. This patch ensures we do this, so you don't get weird behavior with static functions.
-
Arjun P authored
-
Simon Pilgrim authored
Fix parameter name typos and drop returns statements from void functions
-
Simon Pilgrim authored
The MMX pack/unpck shuffles don't need an override - they have the same behaviour as other shuffles (Port0 only). The SSE pslldq/psrldq shuffles don't need an override - they have the same behaviour as other shuffles (Port0 only). The SSE pshufb shuffles use 4uops (+1 load). Noticed the pslldq/psrldq issue while trying to improve reduction costs via the D103695 helper script, and fixed the others while reviewing. Confirmed with Intel AoM / Agner / InstLatX64.
-
Simon Pilgrim authored
Avoid unnecessary copies, reported by MSVC static analyzer.
-
Simon Pilgrim authored
Avoid unnecessary copies, reported by MSVC static analyzer.
-
Simon Pilgrim authored
Avoid unnecessary copies, reported by MSVC static analyzer.
-
Simon Pilgrim authored
Avoid unnecessary copies, reported by MSVC static analyzer.
-
Arjun P authored
Reviewed By: Groverkss, grosser Differential Revision: https://reviews.llvm.org/D109892
-
Arjun P authored
Reviewed By: Groverkss, grosser Differential Revision: https://reviews.llvm.org/D109896
-
Arjun P authored
Reviewed By: Groverkss Differential Revision: https://reviews.llvm.org/D109897
-
Jonas Paulsson authored
The .machine directive can be used in assembly files to specify the ISA for the instructions following it. Review: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D109660
-
Petar Avramovic authored
Rework getConstantstVRegValWithLookThrough in order to make it clear if we are matching integer/float constant only or any constant(default). Add helper functions that get DefVReg and APInt/APFloat from constant instr getIConstantVRegValWithLookThrough: integer constant, only G_CONSTANT getFConstantVRegValWithLookThrough: float constant, only G_FCONSTANT getAnyConstantVRegValWithLookThrough: either G_CONSTANT or G_FCONSTANT Rename getConstantVRegVal and getConstantVRegSExtVal to getIConstantVRegVal and getIConstantVRegSExtVal. These now only match G_CONSTANT as described in comment. Relevant matchers now return both DefVReg and APInt/APFloat. Replace existing uses of getConstantstVRegValWithLookThrough and getConstantVRegVal with new helper functions. Any constant match is only required in: ConstantFoldBinOp: for constant argument that was bit-cast of float to int getAArch64VectorSplat: AArch64::G_DUP operands can be any constant amdgpu select for G_BUILD_VECTOR_TRUNC: operands can be any constant In other places use integer only constant match. Differential Revision: https://reviews.llvm.org/D104409
-
Justas Janickas authored
Adds support for a feature macro `__opencl_c_pipes` in C++ for OpenCL 2021 enabling a respective optional core feature from OpenCL 3.0. This change aims to achieve compatibility between C++ for OpenCL 2021 and OpenCL 3.0. Differential Revision: https://reviews.llvm.org/D109306
-
Max Kazantsev authored
-