[all-commits] [llvm/llvm-project] 1bc9dc: Hexagon: Stop excluding some generic compiler-rt f...

[Matt Arsenault via All-commits]

  Branch: refs/heads/users/arsenm/hexagon/runtime-libcalls-stop-excluding-compiler-rt-generics
  Home:   https://github.com/llvm/llvm-project
  Commit: 1bc9dc0859b97e1ee05d1a2407ce68168b7fbbf8
      https://github.com/llvm/llvm-project/commit/1bc9dc0859b97e1ee05d1a2407ce68168b7fbbf8
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2026-08-05 (Wed, 05 Aug 2026)

  Changed paths:
    M llvm/include/llvm/IR/RuntimeLibcalls.td
    M llvm/lib/Target/Hexagon/HexagonSubtarget.cpp
    M llvm/lib/Target/Hexagon/HexagonSubtarget.h

  Log Message:
  -----------
  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>



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications