[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