search for: lowerreturn

Hi LLVM developers, Thank Daniel Sanders, Aditya Nandakumar and Justin Bogner's Tutorial[1]: Head First into GlobalISel about how to port, and Aditya took BPF target as a simple instance: bool BPFCallLowering::lowerReturn(MachineIRBuilder &MIRBuilder,                                   const Value *Val, unsigned VReg) const {   assert(!Val == !VReg && "Return value without a vreg");   MIRBuilder.buildInstr(BPF::RET);   return true; } But how to implement it for RISCV target? https://githu...

MachineRegisterInfo is maintaining a list of live-out registers for the MachineFunction. It contains the return value registers, and is typically created by XXXISelLowering::LowerReturn(). Various passes after instruction selection need to look at this list to determine which physical registers are live in return blocks. Eventually, the register allocators copy these live-out registers onto the return instructions as implicit use operands. Passes after register allocation shouldn...

...address memory location. 6 ;; function epilogue processing here... >From my investigations so far, i64 types should call a custom function in the calling convention for processing this return type. Also, that LowerCall should be modified to have the assigning of frame pointer into er0 and that LowerReturn should be modified in order to store qr0 into the effective address. Please correct me if I'm wrong. My questions are: 1. Are there any target examples that also has this kind of behavior? If there are please let me know so I could study on it. 2. Where does the assigning of frame poin...

...and to facilitate future refactoring and feature work. This patch gets rid of ISD::CALL, ISD::FORMAL_ARGUMENTS, ISD::RET, and ISD::ISD::ARG_FLAGS, as well as the old LowerArguments and LowerCallTo hooks. To replace them, it adds three new TargetLowering hooks: LowerCall, LowerFormalArguments, and LowerReturn. These hooks provide targets with the same information as the special nodes, except in an immediately usable form instead of awkwardly encoded as SDNode operands. The patch also re-works a substantial portion of the target-independent tail-call code. The patch also includes changes for all in-tree...

...wo ways to go about generating one. First, you can edit the call lowering code in clang (clang/lib/CodeGen/TargetInfo.cpp) so the pointer is represented explicitly in IR. Second, you can make the target-independent backend code generate an sret argument in SelectionDAG, by making your target’s “CanLowerReturn” return false. Probably making CanLowerReturn return false for i64 makes sense for your target. If you’re using TableGen’ed calling conventions (*CallingConv.td), the TableGen’ed code will handle this automatically; otherwise, you can write it out explicitly in C++. If you want an example of how...

Hello, LLVM devs. I'm compiling the following simple IR: define dso_local i32 @main(i32 %argc, i8** %argv) { entry: %retval = alloca i32, align 4 %argc.addr = alloca i32, align 4 %argv.addr = alloca i8**, align 8 store i32 0, i32* %retval, align 4 store i32 %argc, i32* %argc.addr, align 4 store i8** %argv, i8*** %argv.addr, align 8 ret i32 0 } using `llc -march=sparc

...e unnecessary differences between targets, and to > facilitate future refactoring and feature work. I quickly looked over the patch and it seems to be a significant cleanup of all really ugly lowering code! Maybe it will be possible to provide some dummy implementation of LowerFormalArguments / LowerReturn (pass everything on stack, etc), so one willing to add new backend won't need to implement such complex piece of code as a first step? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On 9/4/2012 11:16 AM, Khaled Mohammed wrote: > > Is there an option to do sret demotion via a register? if yes, do we > have a Target to see an example implementation? Hi Khaled, Check out X86TargetLowering::LowerReturn, and the call to getSRetReturnReg. The SRetReturnReg looks like a hack (each target that uses it, declares this variable individually), but that seems to be the current way of handling it. -K -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Hi, it seems like SelectionDAGBuilder expects returning of vectors (structures/arrays) to be lowered in either of the two ways: 1. Flatten the complex data types to simple data types, and return them using registers (done by TargetLowering::LowerCallTo) 2. sret demotion: return the address of the complex data type via a stack pointer Is there an option to do sret demotion via a register? if yes,

...wo ways to go about generating one. First, you can edit the call lowering code in clang (clang/lib/CodeGen/TargetInfo.cpp) so the pointer is represented explicitly in IR. Second, you can make the target-independent backend code generate an sret argument in SelectionDAG, by making your target’s “CanLowerReturn” return false. Probably making CanLowerReturn return false for i64 makes sense for your target. If you’re using TableGen’ed calling conventions (*CallingConv.td), the TableGen’ed code will handle this automatically; otherwise, you can write it out explicitly in C++. If you want an example of how...

...PR:%vreg0 %R0<def> = COPY %vreg0; GPR:%vreg0 BX_RET pred:14, pred:%noreg, %R0<imp-use> The important point here is that the BX_RET has some kind of <imp-use> of the registers that will be used to return (%R0 in this case). It gets added first in XYZTargetLowering::LowerReturn, and then selected in the .td file using a variadic node. Which other target's LowerReturn are you using? That's probably the first thing we should check is doing its job. The pictures from of "llc -view-isel-dags" and "llc -view-sched-dags" on a simple function returni...

...all targets > (int64_t would in almost every case map to i64, and this straight > return should be fine, particularly if it comes from C++). So are you > using a custom target and does it have any quirks that might be > relevant? The key functions to look at would be LowerCall and > LowerReturn in XYZISelLowering.cpp. > > Cheers. > > Tim. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170712/3a92a864/attachment-0001.html>

Hello, everyone, I encounter a strange problem about llvm type i64 and C++ type int64_t. I instrumented a program to call the function 'myFunction' in the C++ shared library. 'myFunction' is something like this: int64_t myFunction() { int64_t retValue; ... std::cout << "retValue: " << retValue << "\n"; return retValue; }

...ering. For RISCV, there's no "CCAssignFnForCall" or "CCAssignFnForReturn" functions defined, just like the solution in Mips, a new target-specific "ValueHandler" will be created to support calllowering. I have made some experiment that trying to implement the "LowerReturn" function, and it can return correctly. The code snippet may be as follows: ... CCState CCInfo(F.getCallingConv(), F.isVarArg(), MF, ArgLocs, F.getContext()); TLI.analyzeOutputArgs(MF, CCInfo, Outs, true, nullptr); RISCVValueHandler RetHandler(MIRBuilder, MF.getRegInfo(), Ret); RetHa...

...e refactoring and feature work. > > This patch gets rid of ISD::CALL, ISD::FORMAL_ARGUMENTS, ISD::RET, and > ISD::ISD::ARG_FLAGS, as well as the old LowerArguments and LowerCallTo > hooks. To replace them, it adds three new TargetLowering hooks: > LowerCall, LowerFormalArguments, and LowerReturn. These hooks provide > targets with the same information as the special nodes, except in an > immediately usable form instead of awkwardly encoded as SDNode > operands. The patch also re-works a substantial portion of the > target-independent tail-call code. The patch also includes chan...

On 8 March 2014 00:53, Owen Anderson <resistor at mac.com> wrote: > ISDOpcodes.h contains what documentation there is on the semantics of each > opcode. And TargetOpcodes.h for a few of the post-ISel ones (mostly they're in MachineInstr form, but you'll see them with -view-sched-dags, and occasionally before). Tim.

...GISel::LowerArguments SelectionDAGLowering::LowerCallTo SelectionDAGLowering::visitRet These functions are responsible for breaking up LLVM IR values into register-sized pieces and handing them off to target-specific code through these virtual functions: TLI.LowerFormalArguments TLI.LowerCall TLI.LowerReturn (Actually, SelectionDAGLowering::LowerCallTo calls TargetLowering::LowerCallTo, which calls TargetLowering::LowerCall, for historical reasons.) Basically, the task here is to interpose code which will recognize when an automatic sret is needed, set up a static alloca to hold the value (see the St...

> I recently made a major reorganization of the calling-convention > lowering code which cleared away one of the major obstacles to > doing this within codegen. > > Dan So what was the obstacle, and how was it cleared? And how do you see the large struct return working in codegen? Anything you care to tell me would be welcome. I will be starting on this today or tomorrow.

Hello, I'm part of the (sadly fairly small) community of PS2 hackers. The current cross-toolchain for the PS2 is based on GCC 3.2.3, an outdated and buggy compiler, which I have personally gotten tired of working with, so I would like to port Clang as a newer cross-compiler for the PS2. However, the PS2 has some notable quirks which make this a non-trivial task for the current compiler. It

Hi Lee, > let isReturn = 1, isTerminator = 1, isBarrier = 1 in > { > def RET : BitscuitInst<(outs),(ins),"JMP\tR6",[(Bitscuit_return)]>; > > def JMP : BitscuitInst<(outs), (ins jmptarget:$dst),"JMP\t$dst",[(br > bb:$dst)]>; > } Ah! It looks like the isReturn is to blame then. LLVM is presumably going through adding an implicit use of any