The crypto extension have several shorthand extensions that don't consist of any extra instructions.
Take `zk` for example, while the extension would imply `zkn, zkr, zkt`. The 3 extensions should also
combine back into `zk` to maintain the canonical order in isa strings.
This patch addresses the above.
Reviewed By: VincentWu
Differential Revision: https://reviews.llvm.org/D119530
This commit adds support for processing tablegen include files, and importing
various information from ODS. This includes operations, attribute+type constraints,
attribute/operation/type interfaces, etc. This will allow for much more robust tooling,
and also allows for referencing ODS constructs directly within PDLL (imported interfaces
can be used as constraints, operation result names can be used for member access, etc).
Differential Revision: https://reviews.llvm.org/D119900
This patch added the MC layer support of Zfinx extension.
Authored-by: StephenFan
Co-Authored-by: Shao-Ce Sun
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D93298
WithColor has an "auto detection mode" which looks whether the
corresponding whether the corresponding cl::opt is enabled or not. While
this is great when opting into cl::opt, it's not so great for downstream
users of this utility, which might have their own competing options to
enable or disable colors. The WithColor constructor takes a color mode,
but the big benefit of the class are its static error and warning
helpers and default error handlers.
In order to allow users of this utility to enable or disable colors
globally, this patch adds the ability to specify a global auto detection
function. By default, the auto detection function behaves the way that
it does today. The benefit of this patch lies in that it can be
overwritten. In addition to a ability to change the auto detection
function, I've also made it possible to get your hands on the default
auto detection function, so you swap it back if if you so desire.
This patch allow downstream users (like LLDB) to globally disable colors
with its own command line flag.
Differential revision: https://reviews.llvm.org/D120593
WithColor has an "auto detection mode" which looks whether the
corresponding whether the corresponding cl::opt is enabled or not. While
this is great when opting into cl::opt, it's not so great for downstream
users of this utility, which might have their own competing options to
enable or disable colors. The WithColor constructor takes a color mode,
but the big benefit of the class are its static error and warning
helpers and default error handlers.
In order to allow users of this utility to enable or disable colors
globally, this patch adds the ability to specify a global auto detection
function. By default, the auto detection function behaves the way that
it does today. The benefit of this patch lies in that it can be
overwritten. In addition to a ability to change the auto detection
function, I've also made it possible to get your hands on the default
auto detection function, so you swap it back if if you so desire.
This patch allow downstream users (like LLDB) to globally disable colors
with its own command line flag.
Differential revision: https://reviews.llvm.org/D120593
Last year I was working at Swift to add support for [Localization of Compiler Diagnostic Messages](https://forums.swift.org/t/localization-of-compiler-diagnostic-messages/36412/41). We are currently using YAML as the new diagnostic format. The LLVM::YAMLParser didn't have a support for multiline string literal folding and it's crucial to have that for the diagnostic message to help us keep up with the 80 columns rule. Therefore, I decided to add a multiline string literal folding support to the YAML parser.
Patch By: @HassanElDesouky (Hassan ElDesouky)
Differential Revision: https://reviews.llvm.org/D102590
Construct LLVM Support module about CSKY target parser and attribute parser.
It refers CSKY ABIv2 and implementation of GNU binutils and GCC.
https://github.com/c-sky/csky-doc/blob/master/C-SKY_V2_CPU_Applications_Binary_Interface_Standards_Manual.pdf
Now we only support CSKY 800 series cpus and newer cpus in the future undering CSKYv2 ABI specification.
There are 11 archs including ck801, ck802, ck803, ck803s, ck804, ck805, ck807, ck810, ck810v, ck860, ck860v.
Every arch has base extensions, the cpus of that arch family have more extended extensions than base extensions.
We need specify extended extensions for every cpu. Every extension has its enum value, name and related llvm feature string with +/-.
Every enum value represents a bit of uint64_t integer.
Differential Revision: https://reviews.llvm.org/D119917
Errors are generally checked in clients by comparing to the portable
error condition in `std::errc`, which will have the `generic_category`
(eg. `std::errc::no_such_file_or_directory`). While in practice these
are usually equivalent for the standard errno's, they are not in *all*
implementations. One such example is CentOS 7.
Differential Revision: https://reviews.llvm.org/D120299
This patch is the first in a series of patches to upstream the support for Apple's DriverKit. Once complete, it will allow targeting DriverKit platform with Clang similarly to AppleClang.
This code was originally authored by JF Bastien.
Differential Revision: https://reviews.llvm.org/D118046
This patch added the MC layer support of Zfinx extension.
Authored-by: StephenFan
Co-Authored-by: Shao-Ce Sun
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D93298
This is a followup to D119695 using the suggestion by joerg. Rather
than manually declaring madvise() on __sun__, this uses
posix_madvise() if available, which does get declared properly on
Illumos.
Differential Revision: https://reviews.llvm.org/D119856
Makes lld-link work in a non-MSVC shell by autodetecting MSVC toolchain. Also
adds support for /winsysroot and a few other switches.
All this is done by refactoring to share code with clang-cl's existing support
for the same.
Differential Revision: https://reviews.llvm.org/D118070
1. Remove computeDefaultABIFromArch and add computeDefaultABI in
RISCVISAInfo.
2. Add parseFeatureBits which may used in D118333.
Differential Revision: https://reviews.llvm.org/D119250
On Windows certain function from `Signals.h` require that `DbgHelp.dll` is loaded. This typically happens when the main program calls `llvm::InitLLVM`, however in some cases main program doesn't do that (e.g. when the application is using LLDB via `liblldb.dll`). This patch adds a safe guard to prevent crashes. More discussion in
https://reviews.llvm.org/D119009.
Reviewed By: aganea
Differential Revision: https://reviews.llvm.org/D119181
The StdQualifiedName node class is used for names exactly in the std
namespace. It is not used for nested names that descend further --
those use a NestedName with NameType("std") as the scope.
Representing the compression scheme in the node graph is layer
breaking. We can use the same structure for those exactly in std too,
and reduce code size a bit.
Reviewed By: ChuanqiXu
Differential Revision: https://reviews.llvm.org/D118249
Lack of ComputeHash inlining slows down slightly FoldingSetBase::FindNodeOrInsertPos calls.
Inlining makes it faster which matters in particular for FoldingSet users in ASTContext.
Extracted from: https://reviews.llvm.org/D118385
Differential Revision: https://reviews.llvm.org/D118612
regcomp.c uses the "start + count < end" idiom to check that there are
"count" bytes available in an array of char "start" and "end" both point
to.
This is fine, unless "start + count" goes beyond the last element of the
array. In this case, pedantic interpretation of the C standard makes
the comparison of such a pointer against "end" undefined, and optimizers
from hell will happily remove as much code as possible because of this.
An example of this occurs in regcomp.c's bothcases(), which defines
bracket[3], sets "next" to "bracket" and "end" to "bracket + 2". Then it
invokes p_bracket(), which starts with "if (p->next + 5 < p->end)"...
Because bothcases() and p_bracket() are static functions in regcomp.c,
there is a real risk of miscompilation if aggressive inlining happens.
The following diff rewrites the "start + count < end" constructs into
"end - start > count". Assuming "end" and "start" are always pointing in
the array (such as "bracket[3]" above), "end - start" is well-defined
and can be compared without trouble.
As a bonus, MORE2() implies MORE() therefore SEETWO() can be simplified
a bit.
Bug report: https://github.com/llvm/llvm-project/issues/47993
Reviewed By: MaskRay, vitalybuka
Differential Revision: https://reviews.llvm.org/D97129
Extend "fallthrough" to allow a third option: "fallback". Fallthrough
allows the original path to used if the redirected (or mapped) path
fails. Fallback is the reverse of this, ie. use the original path and
fallback to the mapped path otherwise.
While this result *can* be achieved today using multiple overlays, this
adds a much more intuitive option. As an example, take two directories
"A" and "B". We would like files from "A" to be used, unless they don't
exist, in which case the VFS should fallback to those in "B".
With the current fallthrough option this is possible by adding two
overlays: one mapping from A -> B and another mapping from B -> A. Since
the frontend *nests* the two RedirectingFileSystems, the result will
be that "A" is mapped to "B" and back to "A", unless it isn't in "A" in
which case it fallsthrough to "B" (or fails if it exists in neither).
Using "fallback" semantics allows a single overlay instead: one mapping
from "A" to "B" but only using that mapping if the operation in "A"
fails first.
"redirect-only" is used to represent the current "fallthrough: false"
case.
Differential Revision: https://reviews.llvm.org/D117937
Lack of AddInteger/AddPointer inlining slows down NodeEquals/Profile/:operator== calls.
Inlining makes FunctionProtoTypes/PointerTypes/ElaboratedTypes/ParenTypes Profile functions faster
but since NodeEquals is still called indirectly through function pointer from FindNodeOrInsertPos
there is room for further inlining improvements.
Extracted from: https://reviews.llvm.org/D118385
Differential Revision: https://reviews.llvm.org/D118610
Add support for the 'pause' hint instruction as an alias for
'fence w, 0'. To do this allow the 'fence' operands pred and succ
to be set to 0 (the empty set). This will also allow future hints
to be encoded as 'fence 0, <x>' and 'fence <x>, 0'.
This patch revised from @mundaym's D93019.
Reviewed By: asb
Differential Revision: https://reviews.llvm.org/D117789
See:
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/40636/consoleFull#-39956214149ba4694-19c4-4d7e-bec5-911270d8a58c
```
llvm/lib/Support/Valgrind.cpp:37:63: error: missing '#include <stddef.h>'; 'size_t' must be declared before it is used
void llvm::sys::ValgrindDiscardTranslations(const void *Addr, size_t Len) {
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.0.0/include/stddef.h:46:23: note: declaration here is not visible
typedef __SIZE_TYPE__ size_t;
^
1 error generated.
```
rdar://88049280
We do support building with a default target unspecified. This fixes
two small build issues that prevented LLVM's unit tests from building
and libSupport from building on Windows.
The spec doesn't seem to be written as if Zfh implies Zfhmin. They
seem to be separate extensions.
This patch moves the instructions from Zfhmin to be enabled with
either the Zfh or Zfhmin extensions.
Reviewed By: achieveartificialintelligence
Differential Revision: https://reviews.llvm.org/D118581
This moves the dependency of several files on include/llvm/ADT/STLExtras.h to
the much shorter llvm/ADT/STLArrayExtras.h
Differential Revision: https://reviews.llvm.org/D118342
serge-sans-paille