[llvm-commits] [PATCH][Review request] Change handling of byval arguments passed in registers.

[Akira Hatanaka]

Hi Bruno,

Are you suggesting front-end (clang) should stop generating byval args
altogether?
That might work, but it is a fairly major change, and I am reluctant
to do that now.

The intent of the patch was to make what seemed to me an ARM specific
implementation more generic. I think it is possible to handle more
than one byvals without changing CallingConvLower.cpp or
CallingConvLower.h, but it probably will not look as simple as the
implementation in the patch.

On Tue, Oct 25, 2011 at 11:50 AM, Bruno Cardoso Lopes
<bruno.cardoso at gmail.com> wrote:
> Hi Akira,
>
> On Tue, Oct 25, 2011 at 4:11 PM, Akira Hatanaka <ahatanak at gmail.com> wrote:
>> This patch enables handling of functions with multiple byval arguments.
>> foo(struct S1 a0, struct S1 a1);
>> This feature hasn't been necessary since it seems that ARM, which was
>> the only user of FirstByValReg, allows just one byval argument being
>> passed.
>>
>> All registers used to pass or receive byval arguments are stored in a
>> map, which obviates the need to rediscover them later.
>>
>> Also, I think the following functions can be simplified if variable
>> FirstByValRegValid is removed. You can tell whether FirstByValReg is
>> valid or not by checking whether it is 0 since enums for registers are
>> non-zero (NoRegister is 0).
>>
>> unsigned getFirstByValReg() { return FirstByValRegValid ? FirstByValReg : 0; }
>> void setFirstByValReg(unsigned r) { FirstByValReg = r;
>> FirstByValRegValid = true; }
>> void clearFirstByValReg() { FirstByValReg = 0; FirstByValRegValid = false; }
>> bool isFirstByValRegValid() { return FirstByValRegValid; }
>
> I may be missing something, but why don't handle this sort of Mips
> requirement in the front-end (clang)?
>


>
> --
> Bruno Cardoso Lopes
> http://www.brunocardoso.cc
>