[mlir][bytecode] Unpack i1 splats to 0x01 (#186221)
Previously the arith folder test would emit `dense<255>` (`0xFF` zero
extended). In-memory without bytecode is `0x01`, so this change ensures
in-memory formats match.
Also changes `0xFF` to `~0x00` since compilation on machines with signed
chars was causing issues, this should ensure it is set to all ones
regardless of char interpretation:
```
[1083/5044] Building CXX object tools/mlir/lib/IR/CMakeFiles/obj.MLIRIR.dir/BuiltinDialectBytecode.cpp.o
/.../BuiltinDialectBytecode.cpp:184:35: warning: result of comparison of constant 255 with expression of type 'const char' is always false [-Wtautological-constant-out-of-range-compare]
184 | if (blob.size() == 1 && blob[0] == 0xFF) {
| ~~~~~~~ ^ ~~~~
1 warning generated.
```
Fixes llvm/llvm-project#186178
[mlir][XeGPU][Transform] Update the xegpu-vector-linearize test with named captures in FileCheck. (#186314)
These tests used to contain specific numbered SSA names (%0, %1, %2,
etc.), this may cause unnecessary issue if a test is updated with new
ops. Update the tests to use named captures instead for future
adaptability.
[clang][bytecode] Remove useless emitCheckAllocations calls (#186385)
The one at the top of visitExpr doesn't make sense (we *just* started
visiting the expression, how can there be leaked allocations?) and the
one at the bottom is already handled via maybeDestroyLocals.
[flang][OpenMP] Account for GenericExprWrapper being null
When getting a MaybeExpr from parser::Expr, take into account that
the GeneticExprWrapper (that wraps MaybeExpr) may itself be null.
[CodeGen] Fix emission of function pointer casts with non-zero program AS (#186210)
Imagine we have the following code:
```c++
void foo() {}
void bar() {
void *ptr = reinterpret_cast<void*>(foo);
}
```
Usually clang would treat this as a simple `bitcast`, but in the case
that the target has a non-default program address space, this needs to
be an `addrspacecast`.
Today, if we try to codegen this, we get an assert due to the two types
not being valid for a `bitcast`.
[15 lines not shown]
[lldb][Module][NFC] Use raw string literal and formatv-style format in LoadScriptingResourceInTarget (#186411)
Makes it obvious what the warning will look like (with the indenentation
etc.). Also adds a test since we had no coverage for the warning before
(as far as I'm aware).
[lldb][PlatformDarwin] Disallow '+' in auto-loadable Python script names (#186346)
The `ScriptInterpreterPython` will refuse to load script names that
contain `+`. This patch makes `SanitizedScriptingModuleName` handle this
by replacing it with `x`. That might seem a bit arbitrary but the way
the current dSYM script loading (and the future "auto-load") mechanism
works is that it will look for scripts called `<lldb-module-name>.py`.
So for something like `libc++.1.dylib`, we would look for `libc++.1.py`.
Replacing `x` with `_` like we do for other special characters would
look strange in my opinion. The simplest way of working around this is
to recommend renaming the script to `libcxx_1.py`.
An alternative to the whole "replace special characters" logic is to
have a MANIFEST file which advertises the script name that LLDB should
load. During reading that script we could bail if we saw special
characters. But I haven't thought that through fully. And since the
`llvm::replace` approach is the path of least resistence I went with it
for now.
[BOLT] Gadget scanner: implement finer-grained --scanners=... argument (#176135)
Add separate options to enable each of the available gadget detectors.
Furthermore, add two meta-options enabling all PtrAuth scanners and all
available scanners of any type (which is only PtrAuth for now, though).
This commit renames `pacret` option to `ptrauth-pac-ret` and `pauth` to
`ptrauth-all`.
bootgrid: require selection to be enabled for delete-selected
Logically, multiSelect should be enabled here as well, but leave this
out for now as it may be too wide.
[VPlan] Prevent uses of materialized VPSymbolicValues. (NFC) (#182318)
After VPSymbolicValues (like VF and VFxUF) are materialized via
replaceAllUsesWith, they should not be accessed again. This patch:
1. Tracks materialization state in VPSymbolicValue.
2. Asserts if the materialized VPValue is used again. Currently it
adds asserts to various member functions, preventing calling them
on materialized symbolic values.
Note that this still allows some uses (e.g. comparing VPSymbolicValue
references or pointers), but this should be relatively harmless given
that it is impossible to (re-)add any users. If we want to further
tighten the checks, we could add asserts to the accessors or override
operator&, but that will require more changes and not add much extra
guards I think.
Depends on https://github.com/llvm/llvm-project/pull/182146 to fix a
[2 lines not shown]
graphics/py-colour: remove deprecated d2to1
d2to1 has been deprecated and archived for years, and its functionality
has been subsumed into plain setuptools.
While here, switch to USE_PYTHON=pep517
PR: 293782
Approved by: Martin Neubauer (maintainer)
[lldb][Module][NFC] Use early-return style in LoadScriptingResourceInTarget (#186392)
Planning on adding more to this function/loop soon. Making it
early-return style (as suggested by the LLVM style guide) makes those
changes easier to reason about.
Drive-by:
* Reduced the indentation of the loop by doing an early-continue if the
`FileSpec` is invalid or doesn't exist
