This is important because *Objects targets need to only depend on other *Objects targets, not on the unsuffixed CAPI rules. Depending on how it is linked in the current setup, it can cause duplicate symbols.
Differential Revision: https://reviews.llvm.org/D117176
We could use vmv.v.i/vmv.v.x whose eew is 32 to lower the i64 splat vector if the i64 constant scalar could be splitted into two same i32 scalar.
Differential Revision: https://reviews.llvm.org/D117079
Using named registers as input or output constraints creates fcvt.d.s
and fcvt.s.d instructions around the inline assembly.
This makes the data unusable by the inline assembly and corrupts
the results of the inline assembly.
This builds on D116521 to add this functionality to Polly without more copy-pasted code.
Reviewed By: beanz
Differential Revision: https://reviews.llvm.org/D116555
TLS initializers, for example constructors of thread-local variables, don't necessarily get called. If a thread was created before a module is loaded, the module's TLS initializers are not executed for this particular thread.
This is why Microsoft added support for dynamic TLS initialization. Before every use of thread-local variables, a check is added that runs the module's TLS initializers on-demand.
To do this, the method `__dyn_tls_on_demand_init` gets called. Internally, it simply calls `__dyn_tls_init`.
No additional TLS initializer that sets the guard needs to be emitted, as the guard always gets set by `__dyn_tls_init`.
The guard is also checked again within `__dyn_tls_init`. This makes our check redundant, however, as Microsoft's compiler also emits this check, the behaviour is adopted here.
Reviewed By: majnemer
Differential Revision: https://reviews.llvm.org/D115456
When constructing an OperationName, the overwhelming majority of
cases are from registered operations. This revision adds a non-locked
lookup into the currently registered operations, which prevents locking
in the common case. This revision also optimizes several uses of
RegisteredOperationName that expect the operation to be registered,
e.g. such as in OpBuilder.
These changes provides a reasonable speedup (5-10%) in some
compilations, especially on platforms where locking is expensive.
Differential Revision: https://reviews.llvm.org/D117187
This commit sometimes causes a crash when compiling a vtable thunk. E.g.:
clang '--target=aarch64-grtev4-linux-gnu' -xc++ - -c -o /dev/null <<EOF
struct a {
virtual int f();
};
struct c {
virtual int &g() const;
};
struct d : a, c {
int &g() const;
};
int &d::g() const {}
EOF
Some follow-up commits have been reverted as well:
Revert "IR: Make getRetAlign check callee function attributes"
Revert "Fix MSVC "32-bit shift implicitly converted to 64 bits" warning. NFC."
Revert "Fix MSVC "32-bit shift implicitly converted to 64 bits" warning. NFC."
This reverts commit 4f414af6a7.
This reverts commit a5507d2e25.
This reverts commit 3d2d208f6a.
This reverts commit 07ddfa95e3.
This guarantees the preconditions of fromCOO; whereas prior to this, one could call the constructor directly with an unsorted tensor, which would cause fromCOO to misbehave.
Reviewed By: aartbik
Differential Revision: https://reviews.llvm.org/D117167
This patch fixes a crash due to following simple program:
> export struct Unit {
> bool operator<(const Unit&);
> };
It would crash since the compiler would set the module ownership for
Unit. And the declaration with a module ownership is assumed to own a
module. But here isn't one. So here is the crash.
This patch fixes this by exiting early if it finds the export decl is
already invalid.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D117093
OpenMP runtime requires depend vec with i64 type and the alignment of
store instruction should be set as 8.
Reviewed By: kiranchandramohan, shraiysh
Differential Revision: https://reviews.llvm.org/D116300
... from testing with MSVC's STL. Mostly truncation warnings and variables that are only used in `LIBCPP_ASSERT`.
Differential Revision: https://reviews.llvm.org/D116878
Update examples and docs to demonstrate using `__lldb_init_module` instead of
the idiom that checks for `lldb.debugger` at the top-level.
```
if __name__ == '__main__':
...
elif lldb.debugger:
...
```
Is replaced with:
```
if __name__ == '__main__':
...
def __lldb_init_module(debugger, internal_dict):
...
```
This change is for two reasons. First, it's generally encouraged not to only
use the convenience singletons (`lldb.{debugger,process,target,etc}`)
interactively from the `script` command. Second, there's a bug where
registering a python class as a command (using `command script add -c ...`),
result in the command not being runnable. Note that registering function-backed
commands does not have this bug.
Differential Revision: https://reviews.llvm.org/D117237
This fixes -fno-semantic-interposition -fsanitize-coverage incompatibility.
-fPIC -fno-semantic-interposition may add dso_local to an external linkage
function. -fsanitize-coverage instrumentation does not clear dso_local when
adding comdat nodeduplicate. This causes a compatibility issue: the function
symbol may be referenced by a PC-relative relocation without using the local
alias. In -shared mode, ld will report a relocation error.
The fix is to either clear dso_local when adding comdat nodeduplicate, or
supporting comdat nodeduplicate. The latter is more appropriate, because a
comdat nodeduplicate is like not using comdat.
Note: The comdat condition was originally added by D77429 to not use local alias
for a hidden external linkage function in a deduplicate comdat. The condition
has been unused since the code was refactored to only use local alias for
default visibility symbols.
Note: `canBenefitFromLocalAlias` is used by clang/lib/CodeGen/CodeGenModule.cpp
and we don't want to add dso_local to default visibility external linkage comdat any
(clang/test/CodeGenCUDA/usual-deallocators.cu).
Differential Revision: https://reviews.llvm.org/D117190
It's not conforming to specify the SAVE attribute more than
once for a variable, but it also doesn't hurt anything and
isn't fatal in other Fortran compilers. Downgrade the
message to a warning for better portability.
Differential Revision: https://reviews.llvm.org/D117153
Causes a crash with the following (creduce'd) test-case:
clang -O3 '--target=aarch64-grtev4-linux-gnu' -xc - -c -o /dev/null <<EOF
int *e;
int f;
int g() {
int h;
int *j = 0;
while (&f - j > 0) {
int k;
k = j;
if (e == j && *e)
k = 5;
h = k;
j++;
}
return h;
}
EOF
This reverts commit 7ce48be0fd.
Clang 13 has a -fsanitize-coverage -fno-semantic-interposition bug (D117190)
which may lead to
`relocation R_X86_64_PC32 cannot be used against symbol` linker error
in -DLLVM_USE_SANITIZE_COVERAGE=ON build when a shared object is built (e.g.
-DLLVM_BUILD_LLVM_DYLIB=on).
For simplicity, just disallow Clang 13 entirely.
Note: GCC -fPIC performance benefits from -fno-semantic-interposition
dramatically. Clang benefits little. Using this option is more for a dogfood
purpose to test correctness of this option, because in the wild some important
packages like CPython uses this option.
Differential Revision: https://reviews.llvm.org/D117183
This completes removal of the isXLike queries, and depends on a whole series of earlier patches which have already landed.
Differential Revision: https://reviews.llvm.org/D117242
The basic idea is that we can parameterize the getObjectSize implementation with a callback which lets us replace the operand before analysis if desired. This is what Attributor is doing during it's abstract interpretation, and allows us to have one copy of the code.
Note this is not NFC for two reasons:
* The existing attributor code is wrong. (Well, this is under-specified to be honest, but at least inconsistent.) The intermediate math needs to be done in the index type of the pointer space. Imagine e.g. i64 arguments in a 32 bit address space.
* I did not preserve the behavior in getAPInt where we return 0 for a partially analyzed value. This looks simply wrong in the original code, and nothing test wise contradicts that.
Differential Revision: https://reviews.llvm.org/D117241
When LLDB receives a SIGINT while running the embedded Python REPL it
currently just crashes in ScriptInterpreterPythonImpl::Interrupt with an
error such as the one below:
Fatal Python error: PyThreadState_Get: the function must be called
with the GIL held, but the GIL is released (the current Python thread
state is NULL)
The faulty code that causes this error is this part of
ScriptInterpreterPythonImpl::Interrupt:
PyThreadState *state = PyThreadState_GET();
if (!state)
state = GetThreadState();
if (state) {
long tid = state->thread_id;
PyThreadState_Swap(state);
int num_threads = PyThreadState_SetAsyncExc(tid, PyExc_KeyboardInterrupt);
The obvious fix I tried is to just acquire the GIL before this code is
running which fixes the crash but the KeyboardInterrupt we want to raise
immediately is actually just queued and would only be raised once the
next line of input has been parsed (which e.g. won't interrupt Python
code that is currently waiting on a timer or IO from what I can see).
Also none of the functions we call here is marked as safe to be called
from a signal handler from what I can see, so we might still end up
crashing here with some bad timing.
Python 3.2 introduced PyErr_SetInterrupt to solve this and the function
takes care of all the details and avoids doing anything that isn't safe
to do inside a signal handler. The only thing we need to do is to
manually setup our own fake SIGINT handler that behaves the same way as
the standalone Python REPL signal handler (which raises a
KeyboardInterrupt).
From what I understand the old code used to work with Python 2 so I kept
the old code around until we officially drop support for Python 2.
There is a small gap here with Python 3.0->3.1 where we might still be
crashing, but those versions have reached their EOL more than a decade
ago so I think we don't need to bother about them.
Differential revision: https://reviews.llvm.org/D104886
Mehdi Amini