search for: ccif

...re I don't know of. How does this information get handled by the TableGen calling-conv code in your situation? The only way I can think of is a custom CCState which gets told about each argument as it passes by and allows CCCustom functions to access its special information (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...

...b/Target/TargetMachine.cpp Also, moving the option there will allow us to change fastcc ABI (callee popping arguments) only when this option is on. See Chris' email: > Sure it can be, you can set up custom predicates, for example the > X86CallingConv.td file has: > > class CCIfSubtarget<string F, CCAction A> > : CCIf<! strconcat("State.getTarget().getSubtarget<X86Subtarget>().", F), A>; > > It would be straight-forward to have a CCIf defined to check some command > line argument. +/// IsEligibleForTailCallElimination - Chec...

...reponse. sorry for that. > >> Hmmm. Ok. So this is due to X86CallingConv.td changes? Unfortunately >> that's not controlled by options. Ok then. >> > > Sure it can be, you can set up custom predicates, for example the > X86CallingConv.td file has: > > class CCIfSubtarget<string F, CCAction A> > : CCIf<!strconcat("State.getTarget().getSubtarget<X86Subtarget> > ().", F), A>; > > It would be straight-forward to have a CCIf defined to check some > command > line argument. I think enabling this as llcbeta for...

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

...t is a pointer then it is returned in register a0 (shadowed in d0 for some targets in GCC). For calling conventions compatible with Turbo/Pure C the first two pointes would also go in a0-a1, and the first three integers in d0-d2 (This is not supported by official GCC as of now). Simply subclassing CCIf and check ValVT or LocVT like this does not work: class CCIfPointer<CCAction A> : CCIf<"LocVT==MVT::iPTR", A> { } Do I have to extend ISD::ArgFlagsTy with a "IsPtr" flag that is populated, maybe in SelectionDAGISel::LowerCallTo and ::LowerArguments? Or is there...

...order to allow tail >> call optimization in a general way. > > Hmmm. Ok. So this is due to X86CallingConv.td changes? Unfortunately > that's not controlled by options. Ok then. Sure it can be, you can set up custom predicates, for example the X86CallingConv.td file has: class CCIfSubtarget<string F, CCAction A> : CCIf<!strconcat("State.getTarget().getSubtarget<X86Subtarget>().", F), A>; It would be straight-forward to have a CCIf defined to check some command line argument. I think enabling this as llcbeta for a few nights makes sense before...

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

...>>> Hmmm. Ok. So this is due to X86CallingConv.td changes? Unfortunately >>> that's not controlled by options. Ok then. >>> >> >> Sure it can be, you can set up custom predicates, for example the >> X86CallingConv.td file has: >> >> class CCIfSubtarget<string F, CCAction A> >> : CCIf<!strconcat("State.getTarget().getSubtarget<X86Subtarget> >> ().", F), A>; >> >> It would be straight-forward to have a CCIf defined to check some >> command >> line argument. I think enabling...

On Sep 25, 2007, at 12:01 AM, Arnold Schwaighofer wrote: >>> FastCC use to be caller pops arguments so there was no stack >>> adjustment after the >>> call to qux. Now FastCC has callee pops arguments on return >>> semantics >>> so the >>> x86 backend inserts a stack adjustment after the call. >>> >>> _array: >>>

...lingConv.td changes? >>>> Unfortunately >>>> that's not controlled by options. Ok then. >>>> >>> >>> Sure it can be, you can set up custom predicates, for example the >>> X86CallingConv.td file has: >>> >>> class CCIfSubtarget<string F, CCAction A> >>> : CCIf<!strconcat("State.getTarget().getSubtarget<X86Subtarget> >>> ().", F), A>; >>> >>> It would be straight-forward to have a CCIf defined to check some >>> command >>> line arg...

...ctors OriginalArgWasF128, OriginalArgWasFloat, > OriginalArgWasFloatVector, OriginalRetWasFloatVector, CallOperandIsFixed. Also > a SpeciallCallingConv field. Provides its own implementation of > AnalyzeFormalArguments etc that fill these vectors. CallOperandIsFixed was needed because the CCIf* classes could tell whether the argument list was variable or not, but couldn't tell whether a particular argument was part of the variable portion of the argument list. At the time, it struck me as odd that this information wasn't part of ArgFlagsTy but I didn't want to add it there be...

...128, OriginalArgWasFloat, >> OriginalArgWasFloatVector, OriginalRetWasFloatVector, CallOperandIsFixed. Also >> a SpeciallCallingConv field. Provides its own implementation of >> AnalyzeFormalArguments etc that fill these vectors. > > CallOperandIsFixed was needed because the CCIf* classes could tell whether the argument list was variable or not, but couldn't tell whether a particular argument was part of the variable portion of the argument list. At the time, it struck me as odd that this information wasn't part of ArgFlagsTy but I didn't want to add it there be...

> > FastCC use to be caller pops arguments so there was no stack > > adjustment after the > > call to qux. Now FastCC has callee pops arguments on return semantics > > so the > > x86 backend inserts a stack adjustment after the call. > > > > _array: > > subl $12, %esp > > movss LCPI1_0, %xmm0 > > mulss

...oat, >>> OriginalArgWasFloatVector, OriginalRetWasFloatVector, CallOperandIsFixed. Also >>> a SpeciallCallingConv field. Provides its own implementation of >>> AnalyzeFormalArguments etc that fill these vectors. >> >> CallOperandIsFixed was needed because the CCIf* classes could tell whether the argument list was variable or not, but couldn't tell whether a particular argument was part of the variable portion of the argument list. At the time, it struck me as odd that this information wasn't part of ArgFlagsTy but I didn't want to add it there be...

Hi all, I changed the code that checks whether a tail call is really eligible for optimization so that it performs the check/fix in SelectionDAGISel.cpp:BuildSelectionDAG() as suggest by Evan. Also eliminated an error that caused the remaining failing test cases in the test-suite. The results look very nice (on darwin x86, r42486). The same number (46) of failing test cases on patched

...tputArg 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, P2]>>; > > I've got a patch which implements it for ARM and X86 (though not HFAs using > the features yet, I'm still musing on the best interface to present there > -- "HFA* byval" for target simpl...

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,

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,