This is an archive of the discontinued LLVM Phabricator instance.

[clang] Add __decay<T> as a builtin template
Needs ReviewPublic

Authored by troyj on Nov 4 2022, 12:37 PM.

Details

Reviewers
bruno
shafik
Summary

__decay(T) exists as a builtin, but does not use template syntax like the other builtin templates __make_integer_seq and __type_pack_element. With template syntax, users can write portable code that uses __decay<T> when it's available but falls back to a __decay<T> in a local namespace when it's not available. Template aliasing can provide the same behavior, but at the cost of longer compile time. It is faster to compile a direct use of a builtin than a use via an alias. This compile time difference is measurable in large TUs that make heavy use of templates. Currently the only performant alternative is to use preprocessor macros in the user's code.

Diff Detail

Event Timeline

troyj created this revision.Nov 4 2022, 12:37 PM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: martong. · View Herald Transcript
troyj requested review of this revision.Nov 4 2022, 12:37 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 4 2022, 12:37 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript

I worry about this mangling issue https://github.com/llvm/llvm-project/issues/54993.
For std::make_index_sequence that wasn't that big of a deal, since nobody really uses that as return type of (template) functions, but my guess is that enough people do things like

template<class T>
decay_t<T> copy(T t);

that this might become a problem here.

Also, it would be nice to have some numbers for the 'measurably faster' claim :)

troyj added a comment.Nov 4 2022, 3:01 PM

Also, it would be nice to have some numbers for the 'measurably faster' claim :)

Sure. Here's an example of a library change that started using builtins for __make_integer_seq and __type_pack_element https://github.com/facebook/fatal/commit/58102a3f7e66ad122d7d3335c446399b09d5085e where there was a 1.8% speedup for a file that spent 70 seconds in the front end. It also reduced the peak memory usage of the front end by 0.5%. We have reason to believe that a __decay builtin would produce similar benefit. Unfortunately, all of the intrinsics in https://reviews.llvm.org/D116203 were implemented with parentheses syntax instead of as builtin templates, which makes it more difficult. Ideally, we'd like to see all of these implemented as builtin templates, but __decay is the first one that we're proposing.

I'm not familiar with the mangling issue that you mentioned. I'll look into it more.

Also, it would be nice to have some numbers for the 'measurably faster' claim :)

Sure. Here's an example of a library change that started using builtins for __make_integer_seq and __type_pack_element https://github.com/facebook/fatal/commit/58102a3f7e66ad122d7d3335c446399b09d5085e where there was a 1.8% speedup for a file that spent 70 seconds in the front end. It also reduced the peak memory usage of the front end by 0.5%. We have reason to believe that a __decay builtin would produce similar benefit. Unfortunately, all of the intrinsics in https://reviews.llvm.org/D116203 were implemented with parentheses syntax instead of as builtin templates, which makes it more difficult. Ideally, we'd like to see all of these implemented as builtin templates, but __decay is the first one that we're proposing.

I'm not familiar with the mangling issue that you mentioned. I'll look into it more.

Is there a reason that parentheses are insufficient? @aaron.ballman and I talked about whether or not using angle-brackets would be a better option at one point and concluded that there wasn't any benefit.