`Opt(flag, func, desc)` registers an option into `Action`.
`OptClass<EmitterC>` is also available if `EmitterC(RK).run(OS)` is capable.
`Action` is defined as `ManagedStatic<cl::opt>` to guarantee to be created
when each registration of emitter is invoked.
`llvm::TableGenMain(argv0, MainFn)` invokes `Action` instead of `MainFn`
Differential Revision: https://reviews.llvm.org/D144351
This patch adds the AANonConvergent abstract attribute. It removes the
convergent attribute from functions that only call non-convergent
functions.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D143228
Instead of having a separate single letter and multiletter ranking
use a unified rank that assigns multiletter a larger value than
single letter.
Once we've ranked the extensions, then we compare using these ranks.
Reviewed By: kito-cheng
Differential Revision: https://reviews.llvm.org/D146273
fixed: #59095
Update libcall signatures to use multivalue return rather than returning via a pointer
when the multivalue features is enabled in the WebAssembly backend.
Reviewed By: tlively
Differential Revision: https://reviews.llvm.org/D146271
The 'ELPM' instruction has three forms:
--------------------------
| form | feature |
| ----------- | -------- |
| ELPM | hasELPM |
| ELPM Rd, Z | hasELPMX |
| ELPM Rd, Z+ | hasELPMX |
--------------------------
The second form is always used in the expansion of the pseudo
instruction 'ELPMBRdZ'. But for devices without ELPMX but only
with ELPM, only the first form can be emitted.
Reviewed By: jacquesguan
Differential Revision: https://reviews.llvm.org/D141221
when certain flags are specified, the Crt0 object files are not linked.
However, the logic for determining which files will always run. This
patch moves that logic so that the basename is only determined if it is
needed.
Differential Revision: https://reviews.llvm.org/D146443
If the stack is not accessible by other threads, e.g., on a GPU, we need
to ensure heap-2-stack will not create a stack version of a pointer that
might be passed to another thread. Since passing through memory is by
default transparent, we need to register a callback and inspect stores
we might look through explicitly.
This is a two part fix. First, we need two Execution Domains (ED) to
track the values of a function. One for incoming values and one for
outgoing values. This was conflated before. Second, at the function
entry we need to look at the incoming information from call sites not
iterate over non-existing predecessors.
Similar to loads, PHIs can be used to introduce non-dynamically unique
values into the simplification "algorithm". We need to check that PHIs
do not carry such a value from one iteration into the next as can cause
downstream reasoning to fail, e.g., downstream could think a comparison
is equal because the simplified values are equal while they are defined
in different loop iterations. Similarly, instructions in cycles are now
conservatively treated as non-dynamically unique. We could do better but
I'll leave that for the future.
The change in AAUnderlyingObjects allows us to ignore dynamically unique
when we simply look for underlying objects. The user of that AA should
be aware that the result might not be a dynamically unique value.
Previously, the GNUELFDumper was the only implementer for Hash Histograms.
This patch moves the implementation for printHashHistogram and
printGnuHashHistogram into the ELFDumper base class, and allows each
derived class to specialize how it outputs that information.
This change also prevents the JSONELFDumper from emitting invalid JSON,
since the shared implementation in LLVMELFDumper no longer emits a
warning message to the output stream.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D137096
llvm-readobj will need the ability to print floats for use in
HashHistograms. This adds that functionality to the ScopedPrinter and
JSONScopedPrinter.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D145277
Somehow having MBState and StructTmType in the definition for wchar was
causing test failures. This should fix those.
Differential Revision: https://reviews.llvm.org/D146476
The base pointer register is reserved by compiler when there is
dynamic size alloca and stack realign in a function. However the
base pointer register is not defined in X86 ABI, so user can use
this register in inline assembly. The inline assembly would
clobber base pointer register without being awared by user. This
patch is to create extra prolog to save the stack pointer to a
scratch register and use this register to reference argument from
stack. For some calling convention (e.g. regcall), there may be
few scratch register.
Below is the example code for such case.
```
extern int bar(void *p);
long long foo(size_t size, char c, int id) {
__attribute__((__aligned__(64))) int a;
char *p = (char *)alloca(size);
asm volatile ("nop"::"S"(405):);
asm volatile ("movl %0, %1"::"r"(id), "m"(a):);
p[2] = 8;
memset(p, c, size);
return bar(p);
}
```
And below prolog/epilog will be emit for this case.
```
leal 4(%esp), %ebx
.cfi_def_cfa %ebx, 0
andl $-128, %esp
pushl -4(%ebx)
...
leal 4(%ebx), %esp
.cfi_def_cfa %esp, 4
```
Differential Revision: https://reviews.llvm.org/D145650
For each expression `e` of the form `*(DRE + n)` (or `*(n + DRE)`), where
`DRE` has a pointer type and `n` is an integer literal, `e` will be
transformed to `DRE[n]` (or `n[DRE]` respectively), if
- `e` is at the left-hand side of an assignment or is an lvalue being casted to an rvalue; and
- the variable referred by `DRE` is going to be transformed to be of `std::span` type.
Reviewed by: jkorous, NoQ
Differential revision: https://reviews.llvm.org/D142795
I didn't refactor the test that's failing on arm64 correctly so it
failed everywhere.
Looks like the step test passes on other aarch64 systems as well as
Darwin. Turn off the xfail and see how far that gets.
This patch adds the wchar header, as well as the functions to convert to
and from wide chars. The header also sets up the definitions for wint
and wchar.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D145995
`__tsan_on_thread_idle` is part of the tsan interface that was not being
exported in shared libraries. Fixes it so that we can link to dynamic
versions of tsan and still call `__tsan_on_thread_idle`.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D146166
When we check for similarity, right now there is no order to how it is checked, except for via the suffix tree ordering.
We can reduce how much structural analysis we perform by checking the the regions in decreasing size. In doing so, we know that if two large sections match, each of their contained regions also match. This allows us to skip the structural checking for each smaller section. IT does require that we use the large regions as a "bridge" to create the canonical mapping between the two regions.
This reduces compile time significantly for some benchmarks. It will not perform as well for programs with many small items.
Reviewer: paquette
Differential Revision: https://reviews.llvm.org/D139338
We can't use initial-exec for the definition of __sancov_lowest_stack
because it gets linked into shared libraries such as the UBSan and
HWASan runtimes on Android. I think we can expect plain thread_local
to work unconditionally in sanitizer_common as several other sanitizers
are already using it, so drop the platform-dependent macro and just use
thread_local in the definition.
Differential Revision: https://reviews.llvm.org/D146351
This improves namespacing, and follows the pattern used for "Kind" enums elsewhere in MLIR.
Reviewed By: aartbik
Differential Revision: https://reviews.llvm.org/D146086
The high level goal of this change is to remove lldbTarget's dependency
on lldbPluginProcessUtility. The reason for this existing dependency is
so that we can create the appropriate UnixSignals object based on an
ArchSpec. Instead of using the ArchSpec, we can instead take advantage
of the Platform associated with the current Target.
This is accomplished by adding a new method to Platform,
CreateUnixSignals, which will create the correct UnixSignals object for
us. We then can use `Platform::GetUnixSignals` and rely on that to give
us the correct signals as needed.
Differential Revision: https://reviews.llvm.org/D146263
