search for: argflagsty

...> 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 because it appeared to be full and I didn't want to make everyone have a 65-bit ArgFlagsTy 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...

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

...> 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 because it appeared to be full and I didn't want to make everyone have a 65-bit ArgFlagsTy 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...

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

...registers) l0 => 3rd 64-bit integer argument register What is the best way to find out whether integer registers or floating pointer registers should be used for argument passing inside TargetLowering::LowerCall? I can get basic information of the structure being passed (for example, by calling ArgFlagsTy::getByValSize() or ArgFlagsTy::getByValAlign() to get size and alignment), but there doesn't seem to be an easy way to find more detailed information. Do I have to get the instance of StructType for structure S1 and analyze it?

...t integer argument register > > What is the best way to find out whether integer registers or floating > pointer registers should be used for argument passing inside > TargetLowering::LowerCall? I can get basic information of the > structure being passed (for example, by calling > ArgFlagsTy::getByValSize() or ArgFlagsTy::getByValAlign() to get size > and alignment), but there doesn't seem to be an easy way to find more > detailed information. Do I have to get the instance of StructType for > structure S1 and analyze it? The way we do stuff like this for x86-64 is adding...

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

.../// all args to reflect changes 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...

...changes 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 ha...

I find the lldb cannot display structure type information, such as "print ArgLocs.size()" as follows, -> 593 CCValAssign &VA = ArgLocs[i]; 594 EVT ValVT = VA.getValVT(); 595 ISD::ArgFlagsTy Flags = Ins[i].Flags; 596 bool IsRegLoc = VA.isRegLoc(); (lldb) print ArgLocs.size() error: call to a function 'llvm::SmallVectorTemplateCommon<llvm::CCValAssign>::size() const' that is not present in the target error: Couldn't materialize struct: Structure hasn't been...

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

...econd solution better. 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 > > _____________...

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

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

.../// all args to reflect changes 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 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 = 0; i < 4; ++i)...

...t;>>> +/// 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 me...

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

...> the function signature for such functions will have to return two results: if the CC processing is finished and if it the func succeeded or failed: typedef bool CCCustomFn(unsigned ValNo, MVT ValVT, MVT LocVT, CCValAssign::LocInfo LocInfo, ISD::ArgFlagsTy ArgFlags, CCState &State, bool &result);

...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? >>>>>&...

...t; +/// 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 st...