[lldb] Add support for synthetic LineEntry objects without valid address ranges (#158811)
Scripted frames that materialize Python functions are PC-less by design,
meaning they don't have valid address ranges. Previously,
LineEntry::IsValid()
required both a valid address range and a line number, preventing
scripted
frames from creating valid line entries for these synthetic stack
frames.
Relaxing this requirement is necessary since
`SBSymbolContext::SetLineEntry`
will first check if the LineEntry is valid and discard it otherwise.
This change introduces an `synthetic` flag that gets set when LineEntry
objects are created or modified through the SBAPI (specifically via
SetLine).
When this flag is set, IsValid() no longer requires a valid address
range,
[9 lines not shown]
[CIR][X86] Add support for `vpcom` builtins (#170362)
Adds support for the `__builtin_ia32_vpcom` and `__builtin_ia32_vpcomu`
X86 builtins.
Part of #167765
---------
Signed-off-by: vishruth-thimmaiah <vishruththimmaiah at gmail.com>
[flang][OpenMP] Generalize checks of loop construct structure
For an OpenMP loop construct, count how many loops will effectively be
contained in its associated block. For constructs that are loop-nest
associated this number should be 1. Report cases where this number is
different.
Take into account that the block associated with a loop construct can
contain compiler directives.
[MLIR] Zero-extend unsigned and 1-bit values when translating IntegerAttr (#169751)
This updates the LLVM IR ConstantInt creation from mlir::IntegerAttr so
that unsigned integers and 1-bit integers are zero-extended rather than
sign-extended.
[flang][OpenMP] Implement loop construct iterator range
Since we're trying to preserve compiler directives in loop constructs,
not every element of the associated parser::Block needs to be a loop
or an OpenMP loop construct. Implement a helper class `LoopRange` to
make it easy to iterate over elements of parser::Block that are loops
or loop constructs.
[flang] [acc] Remove dead code after acc cache directive TODO (#170729)
Remove unreachable code after the TODO in the acc cache directive
lowering function.
[HEXAGON] [MachinePipeliner] Fix the DAG in case of dependent phis. (#135925)
This change corrects the scheduling relationship between dependent PHI
nodes. Previously, the implementation treated SU1 as the successor of
SU0. In reality, SU0 should depend on SU1, not the other way around.
The incorrect ordering could cause SU0 to be scheduled before SU1, which
leads to invalid IR: subsequent instructions may reference values that
have not yet been defined.
%3:intregs = PHI %21:intregs, %bb.6, %7:intregs, %bb.1 - SU0 %7:intregs
= PHI %21:intregs, %bb.6, %13:intregs, %bb.1 - SU1 %27:intregs = A2_zxtb
%3:intregs - SU2
%13:intregs = C2_muxri %45:predregs, 0, %46:intreg
Co-Authored by: Sumanth Gundapaneni
Revert [VPlan] Consolidate logic for narrowToSingleScalars (#170720)
This reverts commit 7b3ec51, as a crash was reported:
https://llvm.godbolt.org/z/dK6ff5zvr -- this will give us time to
investigate a re-land.
[SystemZ] Handle IR struct arguments correctly. (#169583)
- The size of the stack slot was previously computed in LowerCall() by using
the original type, but that didn't work for a struct. Compute the size
by looking at the VT of each part and the number of them instead.
- All the members of a struct have the same OrigArgIndex, so it doesn't work
to assume that following parts belong to a split argument until another
OrigArgIndex is encountered. Use the isSplit() and isSplitEnd() flags
instead.
- Detect any scalar integer argumet >64 bits in CanLowerReturn() instead of
just i128, in order to let all of them be passed on stack.
Fixes #168460
[OpenACC][CIR] Implement 'gang' lowering on `routine' (#170506)
This is a bit more work than the worker/vector/seq in that gang takes an
optional `dim` argument. The argument is always 1, 2, or 3 (constants!),
and the other argument-types that gang allows elsewhere aren't valid
here.
For the IR, we had to add 2 overloads of `addGang`. The first just adds
the 'valueless' one, which can just add to the one ArrayAttr. The second
has to add to TWO lists.
Note: The standard limits to only 1 `gang` per construct. We decided
after evaluating it, that it really means 'per device-type region'.
However, device_type isn't implemented yet, so we'll add tests for that
when we do.
At the moment, we added the device_type infrastructure however.
[NFC] Add missing analysis to `DirectX/llc-pipeline` (#170714)
The Runtime Library Function Analysis pass was added in
https://github.com/llvm/llvm-project/pull/168622 but the backend test
case was not updating accordingly.
