Hexagon: Stop excluding some generic compiler-rt functions from libcalls
RuntimeLibcalls should indicate any function that exists and is callable.
Historically the list of library functions was conflated with the library
functions which should be used, so the library definition was complicated
by excluding the overridden cases. My reading of the compiler-rt sources is
that the generically named functions are built alongside the __hexagon
prefixed variants. e.g., __divsi3 and __hexagon_divsi3 both exist.
It will simplify future libcall work the fewer special case target exclusions
there are, so allow the functions to be defined and apply the selection
preference for the __hexagon prefixed versions in LibcallLoweringInfo.
I do question why compiler-rt is built this way; why doesn't the hexagon
just replace the standard entrypoint names with the target implementations?
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
Add PISA register file, instruction set, and MC layer
Add the PISA register file and register-bank descriptions, the instruction
formats and definitions, and the MC/assembly layer (instruction printer,
register and code encoders, target streamer, MC target description and the
supporting enums), replacing the stub descriptions from
the initial target skeleton.
This provides the instruction-set description and assembly-emission
foundation. The GlobalISel lowering and instruction selection that consume it
are added in the following changes.
RuntimeLibcalls: Add sqrtf to the Hexagon runtime libcall set (#210909)
The library definitions go out of the way to avoid adding sqrtf, in
favor of __hexagon_sqrtf. I'm assuming that libm does provide sqrtf,
it just happens that there is a more-preferred function to use.
RuntimeLibcallsInfo should express the full set of functions that do exist,
and LibcallLoweringInfo should express the preference for which calls
should be used.
By the current ordering rules, it just so happens __hexagon_sqrtf will
win out for SQRT_F32. Add this to avoid a special case to faciliate future
libcall improvements.
Co-authored-by: Claude (Claude-Opus-4.8) <noreply at anthropic.com>
resterm: Update to 0.51.3
Fixed
Text wrapping
The wrapper walked text one rune at a time, which broke down on anything past plain ASCII. Most of the time invisible, but it was an real bug. It now works in grapheme clusters.
* Emoji sequences, combining accents and joined characters no longer get cut in half at a wrap point.
* Zero-width runes no longer count as a cell, so lines containing combining marks stop wrapping earlier than they should have.
* Double-width characters (CJK and similar) can no longer push a row past the pane width. A row that overflowed got wrapped a second time by the terminal, which put the cursor and selection on the wrong line.
* A character too wide to fit beside an indent now moves down whole, and if it still does not fit, the indent is dropped rather than overflowing the row.
* A character wider than the entire row is placed on a row of its own instead of looping.
Row mapping was counted from the size of the output buffer. Blank lines add no bytes, so they were skipped and the map claimed more rows than existed. Cursor movement and selection in bodies with blank lines landed one or more lines off. Rows are counted directly now.
Color handling had two leaks:
* A reset arriving after the last visible character on a line was dropped together with the empty continuation row it landed on, so the color carried into everything below it.
* An escape sequence that appeared inside a run of whitespace was discarded when that whitespace was trimmed at a wrap point.
Also in this area:
* Pre mode no longer produces rows containing only indentation.
* CRLF, control bytes and invalid UTF-8 no longer throw off width accounting or get dropped from the output.
* Extended color codes such as ESC[38;5;0m are read as a color, not as a reset.
[7 lines not shown]
Add PISA target registration and backend stub
Register the Intel GPU portable ISA (PISA) target. Add the pisa Triple
arch, data layout, and a minimal MC/TargetMachine skeleton.
RuntimeLibcalls: Add generic FCMP3_F* three-way compare for single-symbol ABIs
MSP430's __mspabi_cmpd/__mspabi_cmpf are one three-way compare symbol serving
every predicate, previously modeled as six suffixed impls each. Replace them
with a single generic operator FCMP3_*, and give softenSetCCOperands a 3rd
lowering option. After the boolean O*_F* and the per-predicate FCMP3_<pred>_F*
helpers, use the generic FCMP3_F* helper tested with the predicate's condition
code.
Also opt __nedf2 out of the MSP430 default set: it was the only libgcc F64
compare not already opted out, so it would otherwise provide FCMP3_UNE_F64 and
win over __mspabi_cmpd for not-equal.
Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
[offload] Fix unittests on Windows (#214330)
Right now everything fails because it can't find `LLVMOffload.dll`.
We handle this for e2e tests
[here](https://github.com/llvm/llvm-project/blob/main/offload/test/lit.cfg#L212),
but not for the unit tests.
Signed-off-by: Nick Sarnie <nick.sarnie at intel.com>
tests/sys/kern: Skip capsicum procdesc tests when capability mode is unavailable
pdwait's capsicum/enotcap and procdesc's pdopenpid_capmode enter capability mode.
Require security_capability_mode (and security_capabilities for enotcap) so the
cases skip cleanly on kernels built without CAPABILITIES instead of failing.
Approved by: asomers, gallatin
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D58545
bin/sh: Fix history long line truncation/corruption
When reading from standard input with editline history enabled, increase
buffer size to accomodate long lines so that history is recorded
correctly. Cleanup el_gets() handling avoiding potentially dangerous
retention of pointers to editline buffers across calls. Ensure struct
parsefile objects are properly zero initialised when created. Remove
push argument from setinputstring() and simplify logic as it was always
called with a value of one and as was written was potentially dangerous
if ever called with a value of zero.
This commit does not fix long lines when history is enabled but editing
is not (e.g. if there is no terminal).
MFC after: 3 weeks
Pull Request: https://github.com/freebsd/freebsd-src/pull/2028
Signed-off-by: Kristofer Peterson <kris at tranception.com>
(cherry picked from commit 95e4fce8f0c4fc6bf828288b1d63faf0f1300198)
[AMDGPU] Model WMMA co-execution windows in the scheduler for gfx1250
WMMA instructions in gfx1250 expose an execution window during which
only certain other instruction classes may co-execute. Teach the hazard
recognizer about those windows so the scheduler can fill co-execution slots and
account for the resulting stalls. This adds a preRA hazard recognizer
mode.
Add AMDGPUCoExecInfo.h, a shared model of a co-execution window: the
per-stage capability bitmask, the stage types (CoExecStageType), and
CoExecInfo, which maps a multi-cycle instruction to its per-cycle slot
pattern via getCoExecInfo(). InstructionFlavor and its helpers move here
from AMDGPUCoExecSchedStrategy.h with no functional change so they can
be shared by the scheduler and the hazard recognizer.
[lldb][API test] TestRunLocker is flakey, fix (#203429)
TestRunLocker is intended to confirm that certain SB API commands behave
correctly while the inferior process is running. It has two modes - one
where it launches the process stopped, and then resumes it, and another
where it simply launches it. Both are intended to wait until the process
is eStateRunning, and then do the test commands including a
HandleCommand that refers to `lldb.target`.
This test is flakey on Linux and macOS because `lldb.target` comes back
as a None type very early in process setup. We weren't actually running
the "launch to the first instruction, then resume the process" codepath
that this test was written to have - I fixed that last week. But we
still see flakey behavior.
I thought the flakiness might be the private stops we are doing as we're
notified about binaries being loaded in the process, stepping past the
breakpoint in the dynamic loader, and then resume. I tested this theory
by changing the inferior program to be a tight infinite loop, then
[19 lines not shown]
[offload-arch] Fix Intel GPU detection on Windows (#214309)
I found this trying to set up our Windows buildbot.
Manually reproduced the issue and verified the fix.
Signed-off-by: Nick Sarnie <nick.sarnie at intel.com>
