search for: getmachinefunct

Le 15/03/2012 03:07, Akira Hatanaka a écrit : > If you need llvm::Argument, this returns the iterator pointing to the > first argument: > > Function::const_arg_iterator Arg = > DAG.getMachineFunction().getFunction()->arg_begin(); Thanks Akira. Ivan > > On Wed, Mar 14, 2012 at 8:16 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> Hi, >> >> How can I get the llvm-type of the formal argument while lowering it ? >> >> My target needs to map poi...

Our target also use different registers for pointer and non-pointer parameters. > If you need llvm::Argument, this returns the iterator pointing to the > first argument: DAG.getMachineFunction().getFunction() only works in LowerFormalArguments (there it returns the callee), not in LowerCall (where it returns the caller, rather than the callee). You need to pass more information about the function type to LowerCall (besides partial information such as the isVarArg parameter). I can pr...

...o affect > DWARF generation, right? why do we need to affect type generation? we just need to know dwarf type id in the backend, so we can emit it as a constant. I still think lowering eh_typeid_for differently may work. Like instead of doing GV = ExtractTypeInfo(I.getArgOperand(0)) followed by getMachineFunction().getMMI().getTypeIDFor(GV) we can get dwarf type id from I.getArgOperand(0) if it's any pointer to struct type. I'm not familiar with dwarf handling part of llvm, but feels possible.

Hi, How can I get the llvm-type of the formal argument while lowering it ? My target needs to map pointer and non-pointer parameters to different registers. In addition, parameter lowering is address space dependent (another reason why I need such information). Looking at the DAGBuilder, I found that it is dropping it when translating llvm-types to BE types. Even if the base type is saved

If you need llvm::Argument, this returns the iterator pointing to the first argument: Function::const_arg_iterator Arg = DAG.getMachineFunction().getFunction()->arg_begin(); On Wed, Mar 14, 2012 at 8:16 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi, > > How can I get the llvm-type of the formal argument while lowering it ? > > My target needs to map pointer and non-pointer parameters to different >...

Hi Patrik, > DAG.getMachineFunction().getFunction() only works in LowerFormalArguments (there it returns the callee), not in LowerCall (where it returns the caller, rather than the callee). You need to pass more information about the function type to LowerCall (besides partial information such as the isVarArg parameter). > &gt...

...Reg = I->first; if ((TargetRegisterInfo::isVirtualRegister(VirtReg)) && (VRM->getPhys(VirtReg) == REG_Y)) { LiveInterval &LI = LIS->getInterval(VirtReg); unassign(LI, REG_Y); enqueue(&LI); } } RegClassInfo.runOnMachineFunction(VRM->getMachineFunction()); // update reserve reglist So similar to what's done in LRE_WillShrinkVirtReg(), it searches for live intervals where REG_Y is allocated and evicts them for reallocation. I don't know if there's a faster way of doing this but it's working :) About your first question: the reg...

> On Aug 19, 2015, at 3:48 PM, escha via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Aug 19, 2015, at 1:45 PM, Steve King via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> In the targets I know, shifts are >> cheaper than divides in both speed and size. > > From what I remember, udiv by

...JT(SDValue Op, SelectionDAG &DAG) { SDValue Chain = Op.getOperand(0); SDValue Table = Op.getOperand(1); SDValue Index = Op.getOperand(2); DebugLoc dl = Op.getDebugLoc(); MVT PTy = getPointerTy(); JumpTableSDNode *JT = cast<JumpTableSDNode>(Table); ARMFunctionInfo *AFI = DAG.getMachineFunction().getInfo<ARMFunctionInfo>(); SDValue UId = DAG.getConstant(AFI->createJumpTableUId(), PTy); SDValue JTI = DAG.getTargetJumpTable(JT->getIndex(), PTy); #if 1 // @@ GET TABLE BASE: current code Table = DAG.getNode(ARMISD::WrapperJT, MVT::i32, JTI, UId); #else // @ MY ATTEMPT...

On 3 December 2012 10:42, Mayur Pandey <mayurthebond at gmail.com> wrote: > So this seems to be the cause of the problem. I guess you're mixing two different problems. First, is the possible lack of conformance with the ABI you state, which I can't comment since I don't know that ABI very well. Second, is the fact that clang is not printing correct debug information (or is

...tes matter, and If you want the attributes, I think you should pass the attributes and not the whole Function. I’m not sure why MinSize does not trigger with -Os by default, Michael is it intended? > 2) pass a boolean indicating a power-of-2 denominator. > > const Function* Fn = DAG.getMachineFunction().getFunction(); > if (TLI.isIntDivCheap(N->getValueType(0), Fn, true)) > return SDValue(); > > // Target-specific implementation of sdiv x, pow2. > if (SDValue Res = BuildSDIVPow2(N)) > return Res; Did you consider what I suggested, i.e. inverting the o...

...like this: SDValue FOOTargetLowering::LowerFormalArguments( SDValue Chain, CallingConv::ID CallConv, bool isVarArg, const SmallVectorImpl<ISD::InputArg> &Ins, SDLoc dl, SelectionDAG &DAG, SmallVectorImpl<SDValue> &InVals) const { MachineFunction &MF = DAG.getMachineFunction(); MachineRegisterInfo &RegInfo = MF.getRegInfo(); assert(!isVarArg && "VarArg not supported"); // Assign locations to all of the incoming arguments. SmallVector<CCValAssign, 16> ArgLocs; CCState CCInfo(CallConv, isVarArg, DAG.getMachineFunction(), ArgLocs...

...erInfo::isVirtualRegister(VirtReg)) > && (VRM->getPhys(VirtReg) == REG_Y)) > { > LiveInterval &LI = LIS->getInterval(VirtReg); > unassign(LI, REG_Y); > enqueue(&LI); > } > } > RegClassInfo.runOnMachineFunction(VRM->getMachineFunction()); // update reserve reglist > > So similar to what's done in LRE_WillShrinkVirtReg(), it searches for live intervals where REG_Y is allocated and evicts them for reallocation. I don't know if there's a faster way of doing this but it's working :) Looks good. It is prob...

...g.cpp +++ b/lib/Target/X86/X86ISelLowering.cpp @@ -1590,14 +1590,7 @@ X86TargetLowering::LowerReturn(SDValue Chain, RVLocs, *DAG.getContext()); CCInfo.AnalyzeReturn(Outs, RetCC_X86); - // Add the regs to the liveout set for the function. - MachineRegisterInfo &MRI = DAG.getMachineFunction().getRegInfo(); - for (unsigned i = 0; i != RVLocs.size(); ++i) - if (RVLocs[i].isRegLoc() && !MRI.isLiveOut(RVLocs[i].getLocReg())) - MRI.addLiveOut(RVLocs[i].getLocReg()); - SDValue Flag; - SmallVector<SDValue, 6> RetOps; RetOps.push_back(Chain); // Operand #0 =...

On Nov 29, 2011, at 10:24 AM, Borja Ferrer wrote: > Yes, I want the register to be allocatable when there are no stack frames used in the function so it can be used for other purposes. In fact, I looked at how other backends solve this problem, but they are all too conservative by always reserving the register which in my case it is not a good solution because of the performance impact of not

On Sep 28, 2007, at 11:36 AM, <Alireza.Moshtaghi at microchip.com> <Alireza.Moshtaghi at microchip.com> wrote: > I moved my code to 2.1 but still the same. > If I make ADD i16 legal, then it goes through, but it has problem > expanding it to i8. > Should I go ahead and customize it and do the same for all > instructions? > Or there is a more general thing that I

On 8/4/15 11:51 PM, Wangnan (F) wrote: > void bpf_store_half(void *skb, int off, int val) > asm("llvm.bpf.store.half"); > int func() > { > bpf_store_half(0, 0, 0); > return 0; > } > > Compiled with: > > $ clang -g -target bpf -O2 -S -c test.c > > And get this: > > .text > .globl func > .align

Yes, I want the register to be allocatable when there are no stack frames used in the function so it can be used for other purposes. In fact, I looked at how other backends solve this problem, but they are all too conservative by always reserving the register which in my case it is not a good solution because of the performance impact of not having this register available. I find very interesting

I moved my code to 2.1 but still the same. If I make ADD i16 legal, then it goes through, but it has problem expanding it to i8. Should I go ahead and customize it and do the same for all instructions? Or there is a more general thing that I can do? A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chris Lattner Sent:

...SelectionDAG &DAG){ SmallVector<SDOperand, 8> ArgValues; SDOperand Root = Op.getOperand(0); // Return the new list of results. std::vector<MVT::ValueType> RetVT(Op.Val->value_begin(), Op.Val->value_end()); const Function* Fn = DAG.getMachineFunction().getFunction(); std::cout<<Op.Val->getNumValues(); std::cout<<"----------------- "<<__FUNCTION__<<" handling FORMAL_ARGUMENTS of"<<Fn->getName()<<std::endl;std::cout.flush(); for (unsigned ArgNo = 0, e = Op.Val->getNumValues...