SuccessChanges

Summary

  1. [DAG] Match USUBSAT patterns through zext/trunc (details)
  2. [ThinLTO] Fix import of multiply defined global variables (details)
  3. [Loads] Extract helper frunction for available load/store (NFC) (details)
  4. Make sure the interpreter module was loaded before making checks against it (details)
  5. [IR] restrict vector reduction intrinsic types (details)
  6. [Loads] Add optimized FindAvailableLoadedValue() overload (NFCI) (details)
  7. [lldb-vscode] Emit the breakpoint changed event on location resolved (details)
Commit 38ab47c8136d4f928cfd4babb89cb3c7ab783437 by llvm-dev
[DAG] Match USUBSAT patterns through zext/trunc

This patch handles usubsat patterns hidden through zext/trunc and uses the getTruncatedUSUBSAT helper to determine if the USUBSAT can be correctly performed in the truncated form:

zext(x) >= y ? x - trunc(y) : 0 --> usubsat(x,trunc(umin(y,SatLimit)))
zext(x) >  y ? x - trunc(y) : 0 --> usubsat(x,trunc(umin(y,SatLimit)))

Based on original examples:

void foo(unsigned short *p, int max, int n) {
    int i;
    unsigned m;
    for (i = 0; i < n; i++) {
        m = *--p;
        *p = (unsigned short)(m >= max ? m-max : 0);
    }
}

Differential Revision: https://reviews.llvm.org/D25987
The file was modifiedllvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
The file was modifiedllvm/test/CodeGen/X86/psubus.ll
Commit e97aab8d1510a484a19016cf079e1a8f913cf7cd by kbessonova
[ThinLTO] Fix import of multiply defined global variables

Currently, if there is a module that contains a strong definition of
a global variable and a module that has both a weak definition for
the same global and a reference to it, it may result in an undefined symbol error
while linking with ThinLTO.

It happens because:
* the strong definition become internal because it is read-only and can be imported;
* the weak definition gets replaced by a declaration because it's non-prevailing;
* the strong definition failed to be imported because the destination module
  already contains another definition of the global yet this def is non-prevailing.

The patch adds a check to computeImportForReferencedGlobals() that allows
considering a global variable for being imported even if the module contains
a definition of it in the case this def has an interposable linkage type.

Note that currently the check is based only on the linkage type
(and this seems to be enough at the moment), but it might be worth to account
the information whether the def is prevailing or not.

Reviewed By: tejohnson

Differential Revision: https://reviews.llvm.org/D95943
The file was modifiedllvm/lib/Transforms/IPO/FunctionImport.cpp
The file was addedllvm/test/ThinLTO/X86/weak_globals_import.ll
Commit 7c706aa0d88fa2ca99be7951073454b42e1891dd by nikita.ppv
[Loads] Extract helper frunction for available load/store (NFC)

This contains the logic for extracting an available load/store
from a given instruction, to be reused in a following patch.
The file was modifiedllvm/lib/Analysis/Loads.cpp
Commit a83a825e9902b54b315870e9ed85723525208f09 by antonio.afonso
Make sure the interpreter module was loaded before making checks against it

This issue was introduced in https://reviews.llvm.org/D92187.
The guard I'm changing were is supposed to act when linux is loading the linker for the second time (due to differences in paths like symlinks).
This is done by checking `module_sp != m_interpreter_module.lock()` however this will be true when `m_interpreter_module` wasn't initialized, making linux unload the linker module (the most visible result here is that lldb will stop getting notified about new modules loaded by the process, because it can't set the rendezvous breakpoint again after the stepping over it once).
The `m_interpreter_module` is not getting initialize when it goes through this path: https://github.com/llvm/llvm-project/blob/dbfdb139f75470a9abc78e7c9faf743fdd963c2d/lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp#L332, which happens when lldb was able to read the address from the dynamic section of the executable.

What I'm not sure about though, is if when we go through this path if we still load the linker twice on linux. If that's the case then it means we need to somehow set the m_interpreter_module instead of the fix I provide here. I've only tested this on Android.

Differential Revision: https://reviews.llvm.org/D96637
The file was addedlldb/test/API/functionalities/module_load_attach/main.c
The file was addedlldb/test/API/functionalities/module_load_attach/feature.c
The file was modifiedlldb/packages/Python/lldbsuite/test/decorators.py
The file was addedlldb/test/API/functionalities/module_load_attach/TestModuleLoadAttach.py
The file was modifiedlldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp
The file was addedlldb/test/API/functionalities/module_load_attach/Makefile
Commit 215bb15791c6aefdb0810ffa29900dd4215bf8c3 by spatel
[IR] restrict vector reduction intrinsic types

The arguments in all cases should be vectors of exactly one of integer or FP.

All of the tests currently pass the verifier because we check for any vector
type regardless of the type of reduction.
This obviously can't work if we mix up integer and FP, and based on current
LangRef text it was not intended to work for pointers either.

The pointer case from https://llvm.org/PR49215 is what led me here. That
example was avoided with 5b250a27ec.

Differential Revision: https://reviews.llvm.org/D96904
The file was modifiedllvm/lib/IR/Verifier.cpp
The file was modifiedllvm/test/Verifier/reduction-intrinsics.ll
Commit e0615bcd39fd863361ce8eb68aafdfcdcd8b067d by nikita.ppv
[Loads] Add optimized FindAvailableLoadedValue() overload (NFCI)

FindAvailableLoadedValue() accepts an iterator by reference. If no
available value is found, then the iterator will either be left
at a clobbering instruction or the beginning of the basic block.
This allows using FindAvailableLoadedValue() across multiple blocks.

If this functionality is not needed, as is the case in InstCombine,
then we can use a much more efficient implementation: First try
to find an available value, and only perform clobber checks if
we actually found one. As this function only looks at a very small
number of instructions (6 by default) and usually doesn't find an
available value, this saves many expensive alias analysis queries.
The file was modifiedllvm/include/llvm/Analysis/Loads.h
The file was modifiedllvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
The file was modifiedllvm/lib/Analysis/Loads.cpp
Commit 1f21d488bd79a06c9cf405cc5db985fcd71c4f70 by antonio.afonso
[lldb-vscode] Emit the breakpoint changed event on location resolved

VSCode was not being informed whenever a location had been resolved (after being initated as non-resolved), so even though it was actually resolved, the IDE would show a hollow dot (instead of a red dot) because it didn't know about the change.

Differential Revision: https://reviews.llvm.org/D96680
The file was addedlldb/test/API/tools/lldb-vscode/breakpoint-events/dylib.c
The file was modifiedlldb/test/API/tools/lldb-vscode/breakpoint-events/Makefile
The file was modifiedlldb/tools/lldb-vscode/lldb-vscode.cpp
The file was addedlldb/test/API/tools/lldb-vscode/breakpoint-events/TestVSCode_breakpointLocationResolvedEvent.py
The file was addedlldb/test/API/tools/lldb-vscode/breakpoint-events/dylib_loader.c