Update implementation status tables for Memory and String Functions to include other targets.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
In general, I think just listing every target architecture for every function is not scalable. I think we should separate platform independent implementations from platform specific implementations. The platform independent implementations are straightforward to list. We can include the tables only for platform specific implementations. For items like the optimized memory functions, I think we can say something like this:
Platform independent, tiny, byte-by-byte implementations of `memcpy`, ... are available for size sensitive embedded and bare-metal platforms. For performance sensitive use cases, optimized flavors for x86_64, aarch64 and riscv64 are also available.
libc/docs/strings.rst | ||
---|---|---|
56 | What is barebone-aarch32? | |
69 | Should this be aarch32 or the more popular term Arm32? |
I think for the status page, we do need the list of currently available functions / entry points for each officially supported platform. It helps us to quickly identify holes in our entrypoints.txt files as you can see in the lists. As long as we keep the platform classification generic enough, I don't think it will grow too much more. And these tables should be updated whenever there are changes in entrypoints.txt files.
For further implementation / optimization details, we can totally add to another sections or pages, but I think they should be separated from our concrete supported entrypoints.txt status.
What is barebone-aarch32?