search for: ccstate

...bit clunky. Calling convention lowering in LLVM is typically handled by functions conforming to the CCAssignFn typedef: typedef bool CCAssignFn(unsigned ValNo, MVT ValVT, MVT LocVT, CCValAssign::LocInfo LocInfo, ISD::ArgFlagsTy ArgFlags, CCState &State); Notably, these functions are called after type legalisation so an argument/ret has been split to legal value types. In some cases you want more information than is available through this function interface, which leads to a number of backends creating their own CCState subclass: * Mi...

Hi LLVM developers, Don't be quiet :) we need your suggestions for supporting custom CCState, CCAssignFn in D41700. And also RegisterBank in D41653. because it needs to consider about how to support variable-sized register classes concept implemented in D24631. And I think you might have same question when porting to GlobalISel for your Targets, so please give us some directions, thank...

...but we are also tracking the issue for gcc-6/7 branches and gcc-8 trunk. 非常感谢！龙芯战士们临近春节还奋战在Mozilla、Linux Kernel、GCC、Binutils，但依然抽出休息时间审核我的工作，非常感激！ 在 2018年01月13日 18:58, Leslie Zhai 写道: > Hi LLVM developers, > > Don't be quiet :) we need your suggestions for supporting custom > CCState, CCAssignFn in D41700. > > And also RegisterBank in D41653. because it needs to consider about > how to support variable-sized register classes concept implemented in > D24631. > > And I think you might have same question when porting to GlobalISel > for your Targets, so ple...

...4 January 2018 at 17:10, Daniel Sanders via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. Thanks for the insight Daniel, much appreciated. >> * MipsCCState: adds bool vectors OriginalArgWasF128, OriginalArgWasFloat, >> OriginalArgWasFloatVector, OriginalRetWasFloatVector, CallOperandIsFixed. Also >> a SpeciallCallingConv field. Provides its own implementation of &gt...

I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. > On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > This question came about through reviewing work from Leslie Zhai on GlobalISel > support for RISC-V, which also motivated me to revisit code which I've always > felt was a bit c...

...18 at 17:10, Daniel Sanders via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >>> On 3 Jan 2018, at 14:00, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> I haven't dug into the GlobalISel calling convention code much but I can comment on the MipsCCState. > > Thanks for the insight Daniel, much appreciated. > >>> * MipsCCState: adds bool vectors OriginalArgWasF128, OriginalArgWasFloat, >>> OriginalArgWasFloatVector, OriginalRetWasFloatVector, CallOperandIsFixed. Also >>> a SpeciallCallingConv field. Provides it...

...el wrote: > Since there have been no answers, I will have to start at the > beginning. > > One of the first changes I'd like to try is adding the additional > registers and the AAPCS VFP variant calling conventions. Is there a > reason why the ARM Target isn't using the CCState machinery? Please clarify. I am not sure what you mean by CCState machinery. Evan > > > Deep > > On Fri, Dec 5, 2008 at 5:22 PM, Sandeep Patel > <deeppatel1987 at gmail.com> wrote: >> >> Is anybody actively working on additional ARM target support? >>...

Attached is a prototype patch that uses CCState to lower RET nodes in the ARM target. Lowering CALL nodes will come later. This patch does not handle f64 and i64 types. For these types, it would be ideal to request the conversions below: def RetCC_ARM_APCS : CallingConv<[ CCIfType<[f32], CCBitConvertToType<i32>>, CCIfType&lt...

On Dec 27, 2008, at 4:30 AM, Sandeep Patel wrote: > Attached is a prototype patch that uses CCState to lower RET nodes in > the ARM target. Lowering CALL nodes will come later. > > This patch does not handle f64 and i64 types. For these types, it > would be ideal to request the conversions below: i64 isn't Legal on ARM, so it should already be handled. > > > def RetCC_A...

...it handled it. It > must set > +/// isCustom if it handles the arg and returns true. > +typedef bool CCCustomFn(unsigned &ValNo, MVT &ValVT, > + MVT &LocVT, CCValAssign::LocInfo &LocInfo, > + ISD::ArgFlagsTy &ArgFlags, CCState &State, > + bool &result); > > Is it necessary to return two bools (the second is returned by > reference in 'result')? I am confused about the semantics of 'result'. > > Also, a nitpick: > > + unsigned i; > + for (i =...

Is anybody actively working on additional ARM target support? I need Cortex support (ARMv7, VFPv3, and Neon). Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081205/3756d719/attachment.html>

Since there have been no answers, I will have to start at the beginning. One of the first changes I'd like to try is adding the additional registers and the AAPCS VFP variant calling conventions. Is there a reason why the ARM Target isn't using the CCState machinery? Deep On Fri, Dec 5, 2008 at 5:22 PM, Sandeep Patel <deeppatel1987 at gmail.com> wrote: > > Is anybody actively working on additional ARM target support? > > I need Cortex support (ARMv7, VFPv3, and Neon). > > Thank you.

...unsigned int>::push_back(unsigned int const&) + 104 4 llc 0x000000010002d3d3 raise + 27 5 llc 0x000000010002d3e3 abort + 14 6 llc 0x0000000100a0a9e3 llvm::report_fatal_error(llvm::Twine const&) + 0 7 llc 0x00000001005df5f3 llvm::CCState::AnalyzeCallResult(llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, bool (*)(unsigned int, llvm::MVT, llvm::MVT, llvm::CCValAssign::LocInfo, llvm::ISD::ArgFlagsTy, llvm::CCState&)) + 261 8 llc 0x00000001000b62ac llvm::MBlazeTargetLowering::LowerCallResult(llvm::SDValu...

...in https://reviews.llvm.org/D38315 is finished (except one case), but a more robust alternative implementation was suggested. One can indeed argue that my current implementation is a bit fragile, because it involves manually patching up the isel dags for a few cases. The suggestion was to look into CCState and adjusting of the calling convention lowering, inspired by a recent discussion on the list here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120098.html. The benefit of this approach is that I would get most of legalization for free, which is the fragile bit in my approach at the momen...

...in https://reviews.llvm.org/D38315 is finished (except one case), but a more robust alternative implementation was suggested. One can indeed argue that my current implementation is a bit fragile, because it involves manually patching up the isel dags for a few cases. The suggestion was to look into CCState and adjusting of the calling convention lowering, inspired by a recent discussion on the list here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120098.html. The benefit of this approach is that I would get most of legalization for free, which is the fragile bit in my approach at the momen...

...anges and indicates if it handled it. It must set +/// isCustom if it handles the arg and returns true. +typedef bool CCCustomFn(unsigned &ValNo, MVT &ValVT, + MVT &LocVT, CCValAssign::LocInfo &LocInfo, + ISD::ArgFlagsTy &ArgFlags, CCState &State, + bool &result); Is "result" what you refer to as "isCustom" in the comments? Sorry, I am still confused. You mean it could return true but set 'result' to false? That means it has handled the argument but it would not process...

...it handled it. It > must set > +/// isCustom if it handles the arg and returns true. > +typedef bool CCCustomFn(unsigned &ValNo, MVT &ValVT, > + MVT &LocVT, CCValAssign::LocInfo &LocInfo, > + ISD::ArgFlagsTy &ArgFlags, CCState &State, > + bool &result); > > Is "result" what you refer to as "isCustom" in the comments? > > Sorry, I am still confused. You mean it could return true but set > 'result' to false? That means it has handled the argument...

Hi Josef, > Okay, I've done a lot more testing and I now have a .bc file that compiles for x86, sparc, mips but refuses to compile for the mblaze and powerPC backends because of the calling convention. Is there anyone that would know how to fix the microblaze calling convention or point me in the right direction on how to fix it? what does "refuses to compile" mean? I.e. what

Thanks a lot for the suggestions! I will look into using vld1/vst1, sounds good. I am custom lowering the bitcasts, that's now the only place where FP_TO_FP16 and FP16_TO_FP nodes are created to avoid inefficient code generation. I will double check if I can't achieve the same without using these nodes (because I really would like to get completely rid of them). Cheers, Sjoerd.

.... It seems rather cumbersome to embed > multi-line c++ code in td files. > > Evan >> >> >> typedef bool CCCustomFn(unsigned ValNo, MVT ValVT, >> MVT LocVT, CCValAssign::LocInfo LocInfo, >> ISD::ArgFlagsTy ArgFlags, CCState &State, >> bool &result); >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________...