similar to: Splitting BB pre SelectionDAG

Hi Liad, I'm not an expert in MC, but what you describe doesn't sound any different from how you would handle a branch instruction. Create an MCSymbol that represents the address of the target instruction; use that symbol as an operand in the referencing instruction; emit the symbol as a label just prior to emitting the target instruction. The second and third steps can occur in either

Hey Paul, first of all thank you for taking the time to answer me, if I understand you correctly, I need to modify the instruction it self so one of it's operands is a symbol, and then at MC layer handle that symbol and add an entry to the symtab for that label? What kind of symbol should I use doing such thing? external symbol or MCSymbol? I was trying to find where in the code during the MC

Hey Tim, thanks for the quick answer, this looks exactly like what I was trying to achieve, I was hoping there was something more clean, I was wondering how the community would accept a change in the TD, if the code at CallinvConvLower.cpp:138 would've passed the IsFixed flag to the AssignFn then all those workarounds wouldn't be needed, this example is only one of a few I can think of for

Hey, I am working on a new back-end, in my back end, I require to pass every argument through a register when calling a function, unless the argument is part of the ellipsis (...) and then pass it through the stack, I've tried creating a CCCustom function to analyze the operands when a function has var args, however, the information whether the out val is fixed or not is not passed into the

Hi everyone, I am fairly new to LLVM, I'm working on a new backend. I am trying to add information to a specific instruction using the .symtab in the ELF format. I've been searching through the LLVM source code trying to find a way to do such a thing. Can anyone help me with some directions or point me to some documents in the matter. Thanks, Liad. -------------- next part --------------

Hey all, There seems to be two conventions for git repo directory layout. The official docs suggest the following tree. http://llvm.org/docs/GettingStarted.html#git-mirror llvm (llvm repo) -> tools -> clang (clang repo) -> lld (lld repo) etc. However various llvm-project repos, suggest a different layout: https://github.com/llvm-project/llvm-project-20170507

The first layout is older, and the second is newer. Going forward, things are likely to move around. The second layout is more flexible because it doesn't put any repo inside another repo, so I would recommend adopting it. At the very least, using it will put you in a good position to adapt to any future layout changes. On Mon, Feb 19, 2018 at 1:36 AM Liad Mordekoviz via llvm-dev <

Greetings, I am rather new to LLVM, so please excuse my limited knowledge about it. Currently I am trying to modify the X86TargetLowering::LowerCALL method by inserting additional instructions before the call. As far as I understand, nodes are created by calling the getNode method on the DAG. If, for example, I insert the following code Ops.push_back(Chain); Chain = DAG.getNode(ISD::TRAP,

Thanks to your help I've actually made some progress... Especially the SelectionDAGNodes.h was a good hint. But there are still some things that I can't figure out: // 'mov eax, 41' Chain = DAG.getCopyToReg(Chain, DAG.getRegister(X86::EAX, MVT::i32), DAG.getConstant(41, MVT::i32), InFlag); InFlag = Chain.getValue(1); // 'inc eax' SDValue eaxVal =

On Jun 25, 2009, at 2:05 PM, Artjom K. wrote: > > Greetings, > > I am rather new to LLVM, so please excuse my limited knowledge about > it. > > Currently I am trying to modify the X86TargetLowering::LowerCALL > method by > inserting additional instructions before the call. > As far as I understand, nodes are created by calling the getNode > method on >

> -----Original Message----- > From: Evan Cheng [mailto:evan.cheng at apple.com] > Sent: Wednesday, May 16, 2012 5:30 PM > To: Justin Holewinski > Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu > Subject: Re: [llvm-commits] [PATCH][RFC] Add extra arguments to > TargetLowering::LowerCall() so targets have more context in which to > construct call chains > >

On Apr 19, 2012, at 11:15 AM, Justin Holewinski wrote: > > From: Evan Cheng [mailto:evan.cheng at apple.com] > Sent: Thursday, April 19, 2012 10:47 AM > To: Justin Holewinski > Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu; Vinod Grover > Subject: Re: [llvm-commits] [PATCH][RFC] Add extra arguments to TargetLowering::LowerCall() so targets have more context in which

In response to this discussion, I've prepared the attached patch as an initial prototype for the LowerCall/LowerCallTo change. All of the information currently needed by the back-ends, and the extra information needed by the NVPTX back-end, is now wrapped in a CallLoweringInfo struct. The various SelectionDAG classes have been modified so any calls to TargetLowering::LowerCallTo use this

From: Evan Cheng [mailto:evan.cheng at apple.com] Sent: Thursday, April 19, 2012 10:47 AM To: Justin Holewinski Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu; Vinod Grover Subject: Re: [llvm-commits] [PATCH][RFC] Add extra arguments to TargetLowering::LowerCall() so targets have more context in which to construct call chains TargetLowering::LowerCall is already a mess, I would really

Thanks. This is going in the right direction IMHO. Obviously, please make sure you add comments to the data structure and convert all the targets first. Also, please don't forget to send an email to llvmdev to warn owners of all the out-of-tree targets about the ABI change. Evan On May 15, 2012, at 6:56 AM, Justin Holewinski <jholewinski at nvidia.com> wrote: > In response to this

On Apr 19, 2012, at 12:46 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Apr 19, 2012, at 11:15 AM, Justin Holewinski wrote: > >> >> From: Evan Cheng [mailto:evan.cheng at apple.com] >> Sent: Thursday, April 19, 2012 10:47 AM >> To: Justin Holewinski >> Cc: llvmdev at cs.uiuc.edu; llvm-commits at cs.uiuc.edu; Vinod Grover >> Subject:

TargetLowering::LowerCall is already a mess, I would really prefer not to extend it any further. It's especially difficult to justify extending it without a use in the open source tree. We really should think hard about how to improve the API in two ways. Perhaps we should wrap the arguments in some struct rather than as individual ones. We should also make it easier to extend it in the

A change has just been committed that changes the interface for TargetLowering::LowerCallTo and TargetLowering::LowerCall. Instead of passing a mess of parameters to these functions, a new structure has been created that encapsulates these parameters. The motivation is that additional fields can be added to this structure (with appropriate changes to SelectionDAGBuilder for populating the new

All, The attached patch adds two extra arguments to TargetLowering::LowerCall: RetTy and Args. These arguments are used in TargetLowering::LowerCallTo() to construct the Ins and OutVals parameters, but are not available to the target via LowerCall(). Some targets require this additional information, and the LowerCallTo() method is not virtual in TargetLowering. Instead of making that method

Hi Evan, On Wed, Nov 15, 2006 at 10:17 -0800, Evan Cheng wrote: > Hi Nickhil, > > The Legalizer expects lower'd call is the node that produce the same > number of values as the non-lowered node. That's what the assertion > is checking. > > Take a look at the LowerCall routine for any other targets. You will > see that in the non-void function case, it