[compiler-rt] [llvm] [RFC][Transforms][IPO] Add func suffix in ArgumentPromotion and DeadArgumentElimination (PR #109899)

[Mircea Trofin via llvm-commits]

mtrofin wrote:

> > What seems to be missing in those discussions, and I'd hope to see more spelled out in a RFC, is the user scenario: why does the function name not reflecting argument changes matter, what user scenario breaks?
> 
> @mtrofin This has been mentioned in the original pull request (#105742). The main reason is to make it easy for bpf tracing. For a func without name change, the kernel tracing community will assume its signature to be the same as defined in the source code (or dwarf). In gcc, this is honored since if func signature changed there will be a suffix and then tracing won't work. Currently user will need additional effort to try alternative solution for tracing. The following are some BPF tracing examples:
> 
> ```
> Kprobe (BPF_PROG_TYPE_KPROBE)
> tools/testing/selftests/bpf/progs/loop6.c
> SEC(“kprobe/virtqueue_add_sgs”)
> int BPF_KPROBE(trace_virtqueue_add_sgs, void *unused, struct scatterlist **sgs, unsigned int out_sgs, unsigned int in_sgs)
> fentry/fexit (BPF_PROG_TYPE_TRACING)
> attach_type: BPF_TRACE_FENTRY, BPF_TRACE_EXIT
> tools/testing/selftests/bpf/progs/test_d_path.c
> SEC(“fentry/flip_close”)
> int BPF_PROG(prog_close, struct file *file, void *id)
> tools/testing/selftests/bpf/progs/socket_cookie_prog.c
> SEC(“fexit/inet_stream_connect”) 
> int BPF_PROG(update_cookie_tracing, struct socket *sock, struct sockaddr *uaddr, int addr_len, int flags)
> 
> ...
> ```
> 
> Those arguments are used by BPF so user can write tracing bpf prog by using argument names. This is much more user friendly then using registers.
> 
> For clang however, since func name remains the same users will assume the same function signature. However if function signature actually changed, the above tracing with (declared func signatures) won't work any more and user then may get incorrect result. User may eventually find why it won't work and try more heavy-weight or less efficient alternatives. But if we have indication to user that func signature has been changed then user will not spend time to even try the default approach (assuming signature the same).

Wouldn't it be more desirable to disable argument promotion on functions you may want to enable tracing? Alternatively, if you had the actual signature of the function (post-argpromotion) available, would that enable a user write a correct probe?

https://github.com/llvm/llvm-project/pull/109899