search for: numgpr

...str r1, [r11, #12] >>> ldr r1, [r11, #76] >> VARegSaveSize is 16 because we store the first 16 bytes of struct byval in r0 to r3. >> >> For the test code/assembly I mentioned, only r1-r3 are used for struct byval. r0 used for return val. >> So, NumGPRs = 3, VARegSize = 12, VARegSaveSize =16(4 byte offset), access of arg1 is going wrong. >> For updated test code: >> struct S114 check114 (int a, struct S114 arg0, struct S114* arg1) { >> ..... >> } >> Only r1, r2 used for struct byval, NumGPRs = 2, VARegSize = 8, VAReg...

...> >>> VARegSaveSize is 16 because we store the first 16 bytes of struct > >>> byval in r0 to r3. > >>> For the test code/assembly I mentioned, only r1-r3 are used for > >>> struct byval. r0 used for return val. > >>> > >>> So, NumGPRs = 3, VARegSize = 12, VARegSaveSize =16(4 byte offset), > >>> access of arg1 is going wrong. > >>> > >>> For updated test code: > >>> > >>> struct S114 check114 (*int a*, struct S114 arg0, struct S114* arg1) { > >>> > >&g...

...> Emitted by, > if (VARegSaveSize) > emitSPUpdate(isARM, MBB, MBBI, dl, TII, -VARegSaveSize, // --> VARegSaveSize is calculated in computeRegArea > MachineInstr::FrameSetup) > > ARMTargetLowering::computeRegArea(..) { > ... > VARegSize = NumGPRs * 4; > VARegSaveSize = (VARegSize + Align - 1) & ~(Align - 1); // --> 8 byte alignment done here > } > Stack pointer decremented to NumGPRs*4 + alignment > NumGPRs = 3 registers > VARegSaveSize = 16 (after considering 8 byte alignment ) > > When the...

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130618/5b2a15e3/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201306181656803_BEI0XT4N.gif Type: image/gif Size: 14036 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130618/5b2a15e3/attachment.gif>

...ring the sdisel phase of call lowering? if (isPPC64 && Arg.getValueType() == MVT::i32) { // FIXME: Should this use ANY_EXTEND if neither sext nor zext? @@ -1946,7 +2285,13 @@ SDOperand PPCTargetLowering::LowerCALL(SDOperand Op, SelectionDAG &DAG, if (GPR_idx != NumGPRs) { RegsToPass.push_back(std::make_pair(GPR[GPR_idx++], Arg)); } else { - MemOpChains.push_back(DAG.getStore(Chain, Arg, PtrOff, NULL, 0)); + if (!isTailCall) + MemOpChains.push_back(DAG.getStore(Chain, Arg, PtrOff, NULL, 0)); + // Calculate and r...

...onDAGISel. > > if (isPPC64 && Arg.getValueType() == MVT::i32) { > // FIXME: Should this use ANY_EXTEND if neither sext nor zext? > @@ -1946,7 +2285,13 @@ SDOperand > PPCTargetLowering::LowerCALL(SDOperand Op, SelectionDAG &DAG, > if (GPR_idx != NumGPRs) { > RegsToPass.push_back(std::make_pair(GPR[GPR_idx++], Arg)); > } else { > - MemOpChains.push_back(DAG.getStore(Chain, Arg, PtrOff, NULL, > 0)); > + if (!isTailCall) > + MemOpChains.push_back(DAG.getStore(Chain, Arg, PtrOff, > NU...

Hello Dale, this is an updated version of the tail call optimization patch for powerpc. could you have a look at it? i added code to support ppc64 (untested, will try to get access to ppc64 on a friend's machine). incorporated evan's formatting suggestions. ;) will run another round of testing (llvm-test) on my powerpc g4/800 when i get the okay to commit. testing on this machine takes

...; >> if (isPPC64 && Arg.getValueType() == MVT::i32) { >> // FIXME: Should this use ANY_EXTEND if neither sext nor zext? >> @@ -1946,7 +2285,13 @@ SDOperand >> PPCTargetLowering::LowerCALL(SDOperand Op, SelectionDAG &DAG, >> if (GPR_idx != NumGPRs) { >> RegsToPass.push_back(std::make_pair(GPR[GPR_idx++], Arg)); >> } else { >> - MemOpChains.push_back(DAG.getStore(Chain, Arg, PtrOff, NULL, >> 0)); >> + if (!isTailCall) >> + MemOpChains.push_back(DAG.getStore(Chain, Arg...

Hi Chandler, That's embarrassing how weird this part of clang is. I have a provisional patch which fixes the problem but underlines clang's problems. I will submit it tonight for comments. суббота, 18 октября 2014 г. пользователь Chandler Carruth написал: > > On Fri, Oct 17, 2014 at 7:51 AM, Anton Korobeynikov < > anton at korobeynikov.info >