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

[vivek pandya via llvm-dev]

I think that to use this information no pass from IPRA is required but we
can do this earlier that IPRA as we have this information from the source
file we can use it to build regmask for relevant call insertion while
generating MI. Thus register allocators will be benefited automatically
even with out IPRA.

-Vivek

On Sat, Jul 16, 2016 at 12:03 AM, vivek pandya <vivekvpandya at gmail.com>
wrote:

> Sorry I forget to add clang mailing list.
>
> -Vivek
>
> On Fri, Jul 15, 2016 at 11:57 PM, vivek pandya <vivekvpandya at gmail.com>
> wrote:
>
>> Hello Clang and LLVM Devs,
>>
>> I have been working to add support for an attribute in clang and LLVM
>> that helps
>> user to guide interprocedural register allocation. But the use case I am
>> having
>> is very limited and thus I belieave it is good to have discussion on this
>> before
>> sending a patch.
>>
>> 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.
>>
>> For this purpose I added support for this attribute in clang and clang
>> codegen
>> this attribute as target dependent attribute and add to declaration. Then
>> IPRA
>> constructs regmask from this and use during the optimization.
>>
>> How ever after disussion on IRC with Joerg Sonnenberger and jroelofs we
>> think
>> that this may effect other areas too. So it would be better to discuss
>> this and
>> implement this as we all agree upon it.
>>
>> Sincerely,
>> Vivek
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160718/20ae3e01/attachment.html>