[llvm-dev] RFC: To add __attribute__((regmask("preserve/clobbered list here"))) in clang

[Mehdi Amini via llvm-dev]

> On Jul 15, 2016, at 1:48 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On Fri, Jul 15, 2016 at 11:57:35PM +0530, vivek pandya via llvm-dev wrote:
>> So for IPRA we have a situation where a function is calling a function
>> which is written in assembly and it is not defined in current module. IPRA's scope is
>> limited to a module so for such externally defined function it uses default
>> calling convention but here as the function is written in assembly user can
>> provide exact register usage detials. So we dicided to mark declration of
>> such
>> function with __attribute__((regmask("clobbered list here"))) so LLVM can
>> construct regmask out of it and use it with IPRA to improve register
>> allocation.
> 
> This situation is actually far more common and not restricted to
> assembly at all. There are a number of functions already that have
> special ABIs with much larger set of preserved registers. A typical
> is __tls_get_addr in many ABIs. At the moment, we need hacks in the
> target specific part of LLVM for handling this. Related (limited)
> approaches for this are the preserve_most and preserve_all calling
> conventions.
> 
> As mentioned in the IRC discussion, there are two important issues to be
> considered here from my perspective.
> 
> (1) I really dislike an attribute providing a clobber list. Whether a
> given register is clobbered or not is an implementation detail of a
> specific version and can easily change. It is also something difficult
> to reason about. The invariance that should be put into the ABI contract
> is the inverse -- what registers a function is going to preserve. That
> is even more important when looking at long time ABI stability. New
> registers are introduced every so often. That shouldn't change the
> meaning of a declaration.

Interestingly your last point is the reason why I'd think a clobber list could be more appropriate for some cases: if I have a hand-written assembly function, and it is clobbering some registers, the fact that the client code enables AVX2 won’t make my routine clobbering these.

Maybe a syntax with +/- could be used to express things like “all vector registers but these”.

> The main reason for using a clobber list seems to be a concern about
> verbosity. I think that can be mostly avoided by allowing the use of
> register classes in the specifier, e.g. all-fp for i387 register,
> all-sse2 for the SSE2 register set, all-avx for the AVX register etc.
> At the same time, I consider a certain verbosity to be useful, since
> ultimately, implementation and interface definition need to be carefully
> compared.
> 
> (2) Should the attribute extend or replace the normal preserved
> registers? Randomly clobbering registers is going to create all kinds of
> fun issues with the backend assumptions. We already have such fun with
> inline assembler. Extend-only semantic is much easier to support. It can
> also be combined with a special CC with minimal default preservation and
> well defined meanings e.g. for arguments passed in registers.

Agree.

Overall I’m unsure how much applicability this attribute feature will have in practice though, or if it is worth the complexity to support it.

— 
Mehdi