[all-commits] [llvm/llvm-project] c68571: 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: c685715fde218d941a976d3f48bf690e7452c02d
      https://github.com/llvm/llvm-project/commit/c685715fde218d941a976d3f48bf690e7452c02d
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2026-07-29 (Wed, 29 Jul 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