search for: lowerargu

What is the difference between these two functions? The header file for TargetLowering class says that LowerArguments must be implemented, but only the Sparc and IA64 backends implement them. X86, PowerPC and CellSPU implement LowerFORMAL_ARGUMENTS, but I can find a setOperationAction that states that they should be lowered. Can someone please explain this for me? Thanks, Micah Villmow Systems Engine...

Hi, In SelectionDAGISel::SelectAllBasicBlocks if (TM.Options.EnableFastISel) FastIS = TLI->createFastISel(*FuncInfo, LibInfo); followed by if (!FastIS) { LowerArguments(Fn); } else { The above implies that implementing FastIS is optional. In contrast to that, testing whether FastIS is actually been used is done by testing if TM.Options.EnableFastISel is set. For example in SelectionDAGISel::LowerArguments SDB->setValue(&Arg, Res); if (...

...able arguments is not support by mips backend in llvm-2.6. int func(int i, ...) { return 0; } llvm-gcc func.c -emit-llvm -c -O3 -o func.bc llc func.bc -relocation-model=static -march=mips -O0 -o func.s Command llc fails: llc:SelectionDAGBuilder.cpp:6440:void llvm::SelectionDAGISel::LowerArguments( llvm::BasicBlock):Assertion 'Invals.size() == Ins.size && "LowerFormalArguments didn't emit the correct number of values!"' failed Does the latest mips backend in svn trunk support variable arguments? Regards -------------- next part -------------- An HTML atta...

> > Yes, you need to override both LowerArguments and LowerCallTo. All of > the current targets / abi's use the default implementation in > SelectionDAGISel.cpp But I guess ARM EABI will be the first. :-) As > far as I can see, this is the only clean way to do it. I expect the > ARM EABI specific implementation will be quite...

...vm-2.6. > > int func(int i, ...) { >   return 0; > } > > llvm-gcc    func.c -emit-llvm -c  -O3   -o func.bc > llc    func.bc -relocation-model=static  -march=mips -O0  -o func.s > > Command llc fails: > llc:SelectionDAGBuilder.cpp:6440:void > llvm::SelectionDAGISel::LowerArguments( > llvm::BasicBlock):Assertion 'Invals.size() == Ins.size && > "LowerFormalArguments > didn't emit the correct number of values!"' failed > > Does the latest mips backend in svn trunk support variable arguments? No. I've seen you updated PR4851...

I have a target whose calling conventions specify that pointer-typed arguments are passed in different registers than same-sized integers. It appears that in the SelectionDAGBuilder, arguments/formals with pointer type are lowered to the corresponding integer MVT (via this path: SelectionDAGISel::LowerArguments llvm::ComputeValueVTs TargetLoweringBase::getValueType TargetLoweringBase::getPointerType ) and from then on there is no way to discriminate them, for example in the CallingConv.td file and so on. None of the functions in the above list are virtual and anyway it seems like a Bad Idea to just...

...g::LowerCallTo transforms all i64 arguments in two i32 > arguments. > > A possible solution is override TargetLowering::LowerCallTo and do not > expand i64 arguments. I don't know if it's a good solution. None > backend overrides this function. Yes, you need to override both LowerArguments and LowerCallTo. All of the current targets / abi's use the default implementation in SelectionDAGISel.cpp But I guess ARM EABI will be the first. :-) As far as I can see, this is the only clean way to do it. I expect the ARM EABI specific implementation will be quite a bit simple...

...ode generator is designed to support efficient and quality code generation for standard register-based microprocessors.", so i want to insert my special DAG building code to the code generator. should i completely replace SelectionDAGISel, or modify SelectionDAGISel when necessary like this: LowerArguments(BasicBlock *LLVMBB) { // code for traditional target ........... for (Function::arg_iterator I = F.arg_begin(), E = F.arg_end(); I != E; ++I, ++Idx) { if (TLI.isStrangeTarget()) { //code for my strange target TLI.HandleArgment(...); cont...

I'm facing a problem with functions arguments. ARM EABI defines that 8-bytes arguments must be 8-bytes aligned. For example: void @f(i32 %a, i64 %b) ARM EABI: r0 <- %a r2,r3 <- %b Darwin: r0 <- %a r1,r2 <- %b void @g(i32 %a, i32 %b, i32 %c) ARM EABI or Darwin: r0 <- %a r1 <- %b r2 <- %c The problem is: I can't differ a i64 argument of two i32 arguments in

...wering code. Alternatively, you can use a "original alignment" attribute (i.e. alignment of unexpanded argument). That would be a 5-bit attribute. Chris, got a better idea? Evan On Feb 9, 2007, at 1:57 PM, Lauro Ramos Venancio wrote: >> >> Yes, you need to override both LowerArguments and LowerCallTo. All of >> the current targets / abi's use the default implementation in >> SelectionDAGISel.cpp But I guess ARM EABI will be the first. :-) As >> far as I can see, this is the only clean way to do it. I expect the >> ARM EABI specific implementatio...

...get/TargetRegisterInfo.cpp:59: virtual const llvm::TargetRegisterClass* llvm::TargetRegisterInfo::getPhysicalRegisterRegClass(unsigned int, llvm::MVT) const: Assertion `BestRC && "Couldn't find the register class"' failed. x86-32: 0. Sparc: 6. Caused by Sparc overriding LowerArguments instead of using the normal lowering for arguments, leading to bad interactions with illegal types. PPC64: 0. PPC32: 0. Alpha: 4. Two failures are heavily intertwined with Alpha overriding LowerCallTo rather than using the normal lowering for calls, leading to bad interactions with illegal...

...lvm::AsmPrinter::AsmPrinter(std::basic_ostream<char, std::char_traits<char>... The stream argument has been changed to llvm::raw_ostream Also had to change std::endls to '\n' in the AssemblyPrinter. 12) getSectionForFunction(*f) to f->getSection() 13) TargetLowering::LowerArguments() fingerprint changed It now takes the SmallVectorImpl<SDValue>& argValues as an output reference parameter and is a void function. 14) TargetLowering::LowerCallTo() has an additional bool argument isInreg BR, -- --Pekka, visit0r @ IRC

...he approach. The goal of the patch is to eliminate a bunch of awkward code, eliminate some unnecessary differences between targets, 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. Th...

...f the patch is to eliminate a bunch of awkward code, > eliminate some unnecessary differences between targets, 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...

In the 2.3 release, we included a list of the major LLVM API changes. If you are working on upgrading your code from 2.3 to 2.4, I'd appreciate it if you could compile a list of the major stumbling blocks you have, so that others can benefit from your experience. Please send any info to the list, thanks! -Chris

...AGBuild.cpp. This is where LLVM IR is translated into the special-purpose instruction-selection IR, which is lower-level. Calls are split up into multiple parts which are eventually lowered into the actual instructions for the calling sequence. The main areas of attention will be SelectionDAGISel::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 (Ac...

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

...ons are: Why is there no dependence between these two instructions? And what needs to be done to ensure there is one? My guess is that we somehow need to unify FixedStack-1 with %0, but it's not clear to me how this would be accomplished. (The store is generated as part of SelectionDAGISel::LowerArguments from lib/CodeGen/SelectionDAG/SelectionDAGBuilder, using the PowerPC-specific code in lib/Target/PowerPC/PPCISelLowering.cpp. The load is generated directly from the "load" in the LLVM IR at some other time.) Thanks very much for any help! Bill -- Bill Schmidt, Ph.D. IBM Advance...

...M considers them to be float in any case and to have a 32bit > representation in memory. Or do I need to handle this equivalence in > the front-end only? If you tell the code generator to promote f32 to f64, it will handle 90% of the work for you. The remaining pieces are in the lowercall/lowerarguments/lower return code, where you do need to specify how these are passed. Usually just saying they are in f64 registers should be enough. -Chris -- http://nondot.org/sabre/ http://llvm.org/

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