[lldb] Add conversions for SBValueList and SBValue to the python bridge.
This patch adds support for:
- PyObject -> SBValueList (which was surprisingly not there before!)
- PyObject -> SBValue
- SBValue -> ValueObjectSP using the ScriptInterpreter
These three are the main remaining plumbing changes necessary before we can get to the meat of actually using ScriptedFrame to provide values to the printer/etc. Future patches build off this change in order to allow ScriptedFrames to provide variables and get values for variable expressions.
stack-info: PR: https://github.com/llvm/llvm-project/pull/178574, branch: users/bzcheeseman/stack/5
[lldb] Make `print` delegate to synthetic frames.
This patch is more of a proposal in that it's a pretty dramatic change to the way that `print` works. It completely delegates getting values to the frame if the frame is synthetic, and does not redirect at all if the frame fails.
For this patch, the main goal was to allow the synthetic frame to bubble up its own errors in expression evaluation, rather than having errors come back with an extra "could not find identifier <blah>" or worse, simply get swallowed. If there's a better way to handle this, I'm more than happy to change this as long as the core goals of 'delegate variable/value extraction to the synthetic frame', and 'allow the synthetic frame to give back errors that are displayed to the user' can be met.
stack-info: PR: https://github.com/llvm/llvm-project/pull/178602, branch: users/bzcheeseman/stack/7
[lldb] Add support for ScriptedFrame to provide values/variables.
This patch adds plumbing to support the implementations of StackFrame::Get{*}Variable{*} on ScriptedFrame. The major pieces required are:
- A modification to ScriptedFrameInterface, so that we can actually call the python methods.
- A corresponding update to the python implementation to call the python methods.
- An implementation in ScriptedFrame that can get the variable list on construction inside ScriptedFrame::Create, and pass that list into the ScriptedFrame so it can get those values on request.
There is a major caveat, which is that if the values from the python side don't have variables attached, right now, they won't be passed into the scripted frame to be stored in the variable list. Future discussions around adding support for 'extended variables' when printing frame variables may create a reason to change the VariableListSP into a ValueObjectListSP, and generate the VariableListSP on the fly, but that should be addressed at a later time.
This patch also adds tests to the frame provider test suite to prove these changes all plumb together correctly.
stack-info: PR: https://github.com/llvm/llvm-project/pull/178575, branch: users/bzcheeseman/stack/6
[lldb] Move ValueImpl and ValueLocker to ValueObject, NFC.
This patch moves ValueImpl and ValueLocker to ValueObject.{h,cpp}. This follows the example set in TypeImpl/SBType, where we have something that SBType uses internally that needs to be exposed in the layer below. In this case, SBValue uses ValueImpl, which wraps ValueObject. The wrapper helps avoid bugs, so we want to keep it, but the script interpreter needs to use it and said interpreter is conceptually *below* the SB layer...which means we can't use methods on SBValue.
This patch is purely the code motion part of that, future patches will actually make use of this moved code.
stack-info: PR: https://github.com/llvm/llvm-project/pull/178573, branch: users/bzcheeseman/stack/4
[AArch64] Use GISel for optnone functions (#174746)
Currently, when SDAG is run on AArch64 and an `optnone` function is
encountered, the selector is chosen as FastISel. AArch64 makes use of
GlobalISel at O0 and this patch aims to align `optnone` with this
functionality.
A flag is exposed to enable this functionality for a given backend but,
as AArch64 is currently the only backend I could find using GlobalISel
at O0 this is the only one with it implemented. This flag is set when
the target supports GlobalISel & GlobalISel hasn't been forced by the
user, the target machine or by being at an optimisation level lower than
`EnableGlobalISelAtO`.
If this happens, the GlobalISel passes are included as shown in
`llvm/test/CodeGen/AArch64/O3-pipeline.ll` and skipped by IRTranslator
for functions not marked as `optnone`.
In updating the tests based on this functionality, I found some unused
[5 lines not shown]
[GlobalISel] Provide a fast path for ResetMachineFunctionPass when the function is empty (#177341)
As part of https://github.com/llvm/llvm-project/pull/174746 I
encountered a compile time regression due to ResetMachineFunction
performing full resets on empty functions. In normal operation, this
behaviour is not likely to impact compile time, as the pass is only
inserted when using GlobalISel.
https://github.com/llvm/llvm-project/pull/174746 includes GlobalISel
passes in the SDAG pipeline (only on AArch64) and skips them if a given
function is not optnone surfacing this. By checking if the
MachineFunction is empty we can perform a more lightweight reset that
just sets the required flags, reducing the impact of this change.
[SLP]Support for bswap pattern for bytes-based disjoint or reductions
If the reduction forms reversed bitcast, we can represent it as
a bitcast + bswap, if the source elements are byte sized
Reviewers: hiraditya, RKSimon
Pull Request: https://github.com/llvm/llvm-project/pull/178513
InstCombine: Improve single-use fneg(fabs(x)) SimplifyDemandedFPClass handling
Match the multi-use case's logic for understanding no-nan/no-inf context.
Also only apply the nsz handling in the single use case. alive2 seems to treat
nsz as nondeterministic for each use.
DAG: Handle load in SimplifyDemandedVectorElts
This improves some AMDGPU cases and avoids future regressions.
The combiner likes to form shuffles for cases where an extract_vector_elt
would do perfectly well, and this recovers some of the regressions from
losing load narrowing.
AMDGPU, Arch64 and RISCV test changes look broadly better. Other targets have
some improvements, but mostly regressions. In particular X86 looks much
worse. I'm guessing this is because it's shouldReduceLoadWidth is wrong.
I mostly just regenerated the checks. I assume some set of them should
switch to use volatile loads to defeat the optimization.
[NFC][LLVM] Fix macro redefinition warning in Extensions.cpp (#178555)
Also add missing file header and fixed code to used nested namespace for
definining the anchor function.
[SelectionDAG] Add CTLS to FoldConstantArithmetic and optimize i1 CTLS to 0. (#178552)
Since we don't have a CTLS intrinsic, it likely gets constant folded
while it is still a CTLZ pattern so I'm using a unittest to test it.
[NFCI][OpenMPOpt] replace call to getAllocatedType with getAllocationSize (#178356)
Removes reliance on the exact structure of the declared alloca type,
without changing the behavior of the code here.
[X86] canonicalizeLaneShuffleWithRepeatedOps - avoid folding vperm2x128(vpshufd(load()),undef) -> vpshufd(vperm2x128(load(),undef)) (#178675)
There's no benefit to letting vperm2x128 handle the fold in an unary
shuffle and llvm-mca assumes there's an extra register dependency, which
confuses analysis.
Fixes #178632
