This gets us close to being able to remove a column from the table in
MemoryBuiltins.cpp.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Question for reviewers: if I can do something similar for the aligned versions of ::operator::new in C++, we can remove a column from the table in MemoryBuiltins.cpp. Should that happen in clang, or someplace else? What am I looking for in clang to make that happen?
Patch appears to be stale, general direction looks reasonable. Marking as require changes to indicate author action needed once dependency lands.
I suggest adding the C++ calls here too, especially if that enables removing the column from MemoryBuiltins, as you suggest.
I think only once we've added all of the attributes required to enable us to eliminate the C++ operators from MemoryBuiltins, then we can delete the special handling of C++ operator new in LLVM. and move all the attribute additions into Clang, all at once. (It just seems simpler to deal with by batching it up that way, instead of moving things across the llvm/clang layer piecemeal).
Unlike C allocator functions, we do not annotate operator new in SLC. Operator new annotations are left to clang. I believe you should already find handling for aligned new there and just need to switch it to use the new attribute rather than emitting an alignment assumption.
Except that they _are_ currently special-cased in LLVM, just hardcoded in MemoryBuiltins.cpp vs having attributes defined for the behaviors. It seemed simpler to keep the division of labor between LLVM/Clang, until everything can be moved over at once. But, I don't feel strongly about this -- if you feel the opposite is better, OK.
There's new patches in the stack now (annotated correctly in phabricator) that add the correct attribute-adding stuff to clang, and then removes the allocalign column from the table in MemoryBuiltins.cpp. PTAL?
https://reviews.llvm.org/rG74b1c4c36740fe94953ef648e40df7dd9e9a9c7d
Clang will do the right thing.
I think you'd want to keep this change. It is still relevant for non-clang frontends with an FFI interface. It would seem silly to not infer one particular attribute here while we infer everything else.
Agree, we do want this. The general strategy (which I don't think should be changed) is for LLVM to be aware of standard libc functions, and infer attributes for them. (We do want to get it out of the business of being aware of the C++ stdlib functions, however.)
llvm/lib/Transforms/Utils/BuildLibCalls.cpp | ||
---|---|---|
226 | Just noticed: this was supposed to be hasParamAttribute, not hasFnAttribute. |
LGTM
llvm/lib/Transforms/Utils/BuildLibCalls.cpp | ||
---|---|---|
226 | nit: Drop braces for single-line if. |
Just noticed: this was supposed to be hasParamAttribute, not hasFnAttribute.