[all-commits] [llvm/llvm-project] b968fd: [StrTable] Mechanically convert NVPTX builtins to ...

[Chandler Carruth via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: b968fd95026639a2a1d2057627b41622f3b5c97d
      https://github.com/llvm/llvm-project/commit/b968fd95026639a2a1d2057627b41622f3b5c97d
  Author: Chandler Carruth <chandlerc at gmail.com>
  Date:   2025-01-27 (Mon, 27 Jan 2025)

  Changed paths:
    R clang/include/clang/Basic/BuiltinsNVPTX.def
    A clang/include/clang/Basic/BuiltinsNVPTX.td
    M clang/include/clang/Basic/CMakeLists.txt
    M clang/include/clang/Basic/TargetBuiltins.h
    M clang/include/module.modulemap
    M clang/lib/Basic/Targets/NVPTX.cpp
    M clang/test/CodeGen/builtins-nvptx.c
    M clang/utils/TableGen/ClangBuiltinsEmitter.cpp

  Log Message:
  -----------
  [StrTable] Mechanically convert NVPTX builtins to use TableGen (#122873)

This switches them to use tho common TableGen layer, extending it to
support the missing features needed by the NVPTX backend.

The biggest thing was to build a TableGen system that computes the
cumulative SM and PTX feature sets the same way the macros did. That's
done with some string concatenation tricks in TableGen, but they worked
out pretty neatly and are very comparable in complexity to the macro
version.

Then the actual defines were mapped over using a very hacky Python
script. It was never productionized or intended to work in the future,
but for posterity:

https://gist.github.com/chandlerc/10bdf8fb1312e252b4a501bace184b66

Last but not least, there was a very odd "bug" in one of the converted
builtins' prototype in the TableGen model: it didn't handle uses of `Z`
and `U` both as *qualifiers* of a single type, treating `Z` as its own
`int32_t` type. So my hacky Python script converted `ZUi` into two
types, an `int32_t` and an `unsigned int`. This produced a very wrong
prototype. But the tests caught this nicely and I fixed it manually
rather than trying to improve the Python script as it occurred in
exactly one place I could find.

This should provide direct benefits of allowing future refactorings to
more directly leverage TableGen to express builtins more structurally
rather than textually. It will also make my efforts to move builtins to
string tables significantly more effective for the NVPTX backend where
the X-macro approach resulted in *significantly* less efficient string
tables than other targets due to the long repeated feature strings.



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