[llvm-commits] [llvm] r48459 - in /llvm/trunk/lib/Target/PowerPC: PPCCallingConv.td PPCISelLowering.cpp

Evan Cheng evan.cheng at apple.com
Tue Mar 18 11:54:12 PDT 2008


On Mar 17, 2008, at 11:43 AM, Dale Johannesen wrote:

>
> On Mar 17, 2008, at 11:27 AM, Evan Cheng wrote:
>> The part of call can really use some refactoring. Look at the case of
>> MVT::i32, it can be significantly simplified into something like:
>> unsigned NumValues = Op.Val->getNumValues();
>> if (Op.Val->getValueType(NumValues-1) == MVT::i32)
>> for (unsigned i = 0; i != NumValues; ++i) {
>>  Chain = DAG.getCopyFromReg(Chain, CallRegs[i], MVT::i32,
>> InFlag).getValue(1);
>>  InFlag = Chain.getValue(2);
>>  ResultVals.push_back(Chain.getValue(0));
>>  NodeTys.push_back(MVT::i32);
>> }
>
> I had it like that and decided I prefer this.  Generally I'd rather
> list the cases
> that are supposed to work explicitly rather than have something more
> general
> and trust we won't get handed cases that aren't supposed to happen.
> Shorter is not always better.

I am not sure I see the merit in separating 8 x MVT::i32 from 4 x  
MVT::i32 cases. These are duplicated code. Also if you want clarity,  
why not just list the cases being handled in comments?

I understand this is a matter of taste, but it seems extreme to me.

Evan

>
>
>> BTW, why is it we are using tablegen generated CC code to handle
>> arguments, but not return types (same issue on x86)? I've forgotten
>> the history behind the tablegen CC development.
>
> That is the way I found it.  According to Chris, the PPC BE preceded
> tablegen.  Return values, at least for ppc32, can be handled easily by
> the existing tablegen stuff.  Parameters would need some extensions,
> e.g. same value in both regs and memory, structs passed part in regs
> and part in memory.
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list