So as far as the attribute versus metadata question here I don’t have a particular care whether or not we support attributes on any particular thing in the Value hierarchy. As far as your particular case I really only have one question: are the attributes needed for correctness or for optimization? If they’re the latter they should probably be metadata, the former then attributes seem to make the best sense.
For the particular use case we have, metadata on arguments would be a better semantic fit. It’s a pure optimization hint. Having said that, attributes work just fine in practice as well.
I guess as long as they’re not upstreamed you can do whatever you’d like, I’d suggest the metadata though just to keep within the llvm design principles.
Mostly just trying to see about you getting the right fixes in for the support you need and the rest of us not having to worry about not breaking things that no one cares about
Let me restate my previous comment: Having support for custom attributes on function arguments is generally useful for external users of LLVM. Whether it is ideal in this particular case is not really relevant. There are certainly reasonable cases where using a target/environment specific attribute to effect call lowering makes perfect sense. It seems desireable to be able to prototype these quickly so that they can mature and (possibly) make it upstream.
There’s a lot of things that are generally useful that we delete. I don’t see anything unused in any other way. Bitcode support is a bit more… solid though so removing anything that exists is harder. Misfeatures or things accidentally supported have a tendency to stick around and complicate things.
That said…
My view is that we already support these attributes. I don’t have an example user, but it really wouldn’t surprise me if folks were using this functionality already. Everything works if generated through the C++ APIs or read from bitcode. It’s only the deserialization parts that break. In particular, you can have a working compiler which generates output which isn’t parseable by LLVM’s existing tools. That’s not exactly a good state to be in.
I don’t have a strong opinion here as I said in the first place. If fixing this support is useful then I’ve no objection.
-eric