search for: ccassignfn

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, thanks a lot! 在...

...e 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 please give us...

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 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 s...

...; 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 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...

...se of a Mips quirk. I see Reid Kleckner changed this object last year and found that it wasn't actually full so maybe we should move OutputArg::IsFixed into ArgFlagsTy now. > > AArch64, Hexagon, RISCV, and SystemZ all have the same requirement. > AArch64 works around it by calling its CCAssignFnForCall helper for > every argument (and passing IsFixed through to that). For GISel, it > overrides assignArg so a different function can be called for varargs. > > I'd be in favour of adding IsFixed to ArgFlagsTy even if it did > "overflow" ArgFlagsTy. I know there...

...gsTy just because of a Mips quirk. I see Reid Kleckner changed this object last year and found that it wasn't actually full so maybe we should move OutputArg::IsFixed into ArgFlagsTy now. AArch64, Hexagon, RISCV, and SystemZ all have the same requirement. AArch64 works around it by calling its CCAssignFnForCall helper for every argument (and passing IsFixed through to that). For GISel, it overrides assignArg so a different function can be called for varargs. I'd be in favour of adding IsFixed to ArgFlagsTy even if it did "overflow" ArgFlagsTy. I know there's an argument about &qu...

...formation (or, possibly, a CCIf with a cast). CCCustom<"TellCCStateAboutArg">, [...] CCIf<"cast<MyCCState>(State).isPointerArg()">, CCAssignToReg<[P1, P2]>>, Putting that information in the InputArg/OutputArg and incorporating it the CCAssignFn interface allows a more straightforward implementation in the targets, in my view (for both our uses). It's also information that's readily available when InputArg/OutputArgs are being constructed. In your case: CCIf<"SourceTy->isPointerTy()", CCAssignToReg<[P1, P...

On Wednesday 04 Apr 2012 13:27:07 Tim Northover wrote: > Putting that information in the InputArg/OutputArg and incorporating it the > CCAssignFn interface allows a more straightforward implementation in the > targets, in my view (for both our uses). It's also information that's > readily available when InputArg/OutputArgs are being constructed. In your > case: > > CCIf<"SourceTy->isPointerTy()",...

Hi Tim, > So I've come to the conclusion that the real flaw is LLVM > not exposing enough information to the target-dependent > backend code for it to do the right thing. We also had this problem. You might find this patch useful as a starting point: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048266.html /Patrik Hägglund -----Original Message----- From: llvmdev-bounces

Hi, (Forward from cfe-commits, where some backend stuff has come up). This is an issue I've been thinking about quite a bit recently, and I agree that the biggest problem is the one below: > * The big thing still missing here is that there is no logic to check how many VFP registers have already been used for other arguments. When deciding whether to pass an argument as a homogeneous

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,

Hi all, Over the past few months we’ve been doing work on the foundations for the next stages of GlobalISel development. In terms of changes from this time last year, the IR translator, the legalizer, and instruction selector have seen moderate to major changes. The most significant of these was the change to the legalizer API, allowing targets to use predicates to express legality, which gives