search for: selectiondaglow

...is information in scheduling so that independent memory operations may be reordered. Attached is a patch which implements this. I copied some routines from DAGCombiner.cpp for using SDOperands with alias queries; it should probably be factored out somewhere so the code can be shared. I reorganized SelectionDAGLowering::getLoadFrom a little, to make it simpler to use in other contexts. Also, the patch fixes a bug where SelectionDAG::getLoad and SelectionDAG::getStore were being called with the wrong arguments, with a default argument helping to hide it. I'm interested in any comments or feedback that p...

...looks like the end result is pretty similar. > > Attached is a patch which implements this. I copied some routines from > > DAGCombiner.cpp for using SDOperands with alias queries; it should > > probably be factored out somewhere so the code can be shared. I > > reorganized SelectionDAGLowering::getLoadFrom a little, to make it > > simpler to use in other contexts. > > > > Also, the patch fixes a bug where SelectionDAG::getLoad and > > SelectionDAG::getStore were being called with the wrong arguments, > > with > > a default argument helping to hi...

Hello While building LLVM, the compiler (static analysis) is giving me a warning about "if (RangeUse[0] == 0 && RangeUse[0] == 0) {". Can somebody familar with the codebase look over it, maybe this should be "if (RangeUse[0] == 0 && RangeUse[1] == 0) {", otherwise sorry for the noise. Index: F:/dev/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp

Hi Chris, This is a good idea and I started thinking in that direction already. But what I don't quite understand the TFs, how TFs are formed and which rules they should obey to. For example now: > PendingLoads created by the SelectionDAGLowering::getLoadFrom and then copied into the > TokenFactor node by SelectionDAGLowering::getRoot called from the > SelectionDAGLowering::visitStore So, if I now detect in the getRoot that there are more than let's say 64 nodes in the PendingLoads queue, what should I do? - Can I take onl...

...meant by "very many". In my test-case (you can fetch it from here http://llvm.org/bugs/attachment.cgi?id=1275), which is just one HUGE MBB with tens of thousends of instructions, there is a TokenFactor node N that has ... 3200 operands! (These operands are PendingLoads created by the SelectionDAGLowering::getLoadFrom and then copied into the TokenFactor node by SelectionDAGLowering::getRoot called from the SelectionDAGLowering::visitStore). During the code selection phase, the SelectionDAG::ReplaceAllUsesWith is called many times and in many cases it tried to update this node, by replacin...

...stion. I have implemented the code that : a) does not merge multiple TokenFactor nodes in the DAGCombiner::visitTokenFactor(), if the resulting TF node would contain more than 64 operands. b) produces a bunch of TokenFactor nodes with at most 64 operands, instead of one huge TokenFactor in the SelectionDAGLowering::getRoot(). If we have n pending loads, they can be combined into TFs in two ways: 1) The first 64 loads are put into a new node TF1. Then TF1 and the next 64 loads are put into a new node TF2 and so on. That is, each generated TF contains a previous TF as its first operand and a bunch...

...is 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 (Actually, SelectionDAGL...

Hello, While I was trying to cross-compile Linux OMAP kernel with llvm, I have the following error message. CC arch/arm/kernel/traps.o cc1: /home/wonjeon/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp:5388: void llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallSite): Assertion `(OpInfo.ConstraintType == TargetLowering::C_RegisterClass || OpInfo.ConstraintType == TargetLowering::C_Register) && "Unknown constraint type!"' failed. arch/arm/kernel/traps.c:748: internal compiler error: Aborted Please...

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

It looks like I need to be able to intercept GEP lowering (in SelectionDAGLowering::visitGetElementPtr) and insert something else other than the shifts and adds. The basic problem is that CellSPU loads and stores on 16-byte boundaries. Consequently, the SPU backend has to do the load or store differently than most normal architectures that have byte-addressable opera...

...Are you not getting satisfactory results by turning it on? > > Attached is a patch which implements this. I copied some routines from > DAGCombiner.cpp for using SDOperands with alias queries; it should > probably be factored out somewhere so the code can be shared. I > reorganized SelectionDAGLowering::getLoadFrom a little, to make it > simpler to use in other contexts. > > Also, the patch fixes a bug where SelectionDAG::getLoad and > SelectionDAG::getStore were being called with the wrong arguments, > with > a default argument helping to hide it. Can you be more specif...

I'm getting this: /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp: In member function `void llvm::SelectionDAGLowering::visitSetCC(llvm::User&, llvm::ISD::CondCode, llvm::ISD::CondCode, llvm::ISD::CondCode)': /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1107: error: ` UnsafeFPMath' undeclared (first use this function) /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionD...

...:SDValue, llvm::Type const*, bool, bool, bool, bool, unsigned int, unsigned int, bool, llvm::SDValue, std::vector<llvm::TargetLowering::ArgListEntry, std::allocator<llvm::TargetLowering::ArgListEntry> >&, llvm::SelectionDAG&, llvm::DebugLoc) + 2125 14 lli 0x0864f8c6 llvm::SelectionDAGLowering::LowerCallTo(llvm::CallSite, llvm::SDValue, bool, llvm::MachineBasicBlock*) + 1418 15 lli 0x0865c6b1 llvm::SelectionDAGLowering::visitCall(llvm::CallInst&) + 2527 16 lli 0x08666d1e llvm::SelectionDAGLowering::visit(unsigned int, llvm::User&) + 1108 17 lli 0x08666e1...

I know that many ABIs require this for performance purpose, but I haven't seen anything in the standard that suggests promotion of return value to integer. Furthermore, I think the LLVM is supposed to be independent of language. So I'm not sure if SelectionDAGLowering is the right place for this promotion to begin with, TargetLowering class seems more logical; but I'm not sure how. >> Either way, I think we all agree that the root of the problem is the >> FIXME in SelectionDAGLowering::visitRet() >What I would like to know is if...

...be expanded (to calls) if not fast-math is set... What do you think about this approach? > 4. Don't forget a doc patch to docs/LangRef.html :-) > >> I assume I have to add new nodetypes for the FP instructions to >> SelectionDAGNodes.h, and make nodes for these in >> SelectionDAGLowering::visitCall when I find the intrinsic... OK, I will. >> -- for me it would make most sense to lower the intrinsic to a call if >> it's not supported. However I notice that for other intrinsics (memcpy >> etc.) this is done in LegalizeDAG where the node is expanded to a...

...ing convention and check for it in visitRet Dan replied to thread (2) and suggested to add a new field to the TargetLowering class, and then let each target specify the minimum integer type to promote return types to Either way, I think we all agree that the root of the problem is the FIXME in SelectionDAGLowering::visitRet() But what is the preferred method? Thanks Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080514/32e4e5d1/attachment.html>

On Aug 28, 2007, at 7:02 AM, Dan Gohman wrote: > On Mon, Aug 27, 2007 at 07:26:55PM -0700, Scott Michel wrote: >> It looks like I need to be able to intercept GEP lowering (in >> SelectionDAGLowering::visitGetElementPtr) and insert something else >> other than the shifts and adds. The basic problem is that CellSPU >> loads and stores on 16-byte boundaries. Consequently, the SPU backend >> has to do the load or store differently than most normal >> architectures that...

Hello everybody, I use a target specific Intrinsic that returns an illegal type. The idea is that this returned value shall be eliminated when the Intrinsic node is lowered to a target node. I realize that this is a rather late stage, since (at least) SelectionDAGLowering::visitTargetIntrinsic() requires legal types, and type legalization in general is also done before ISelLowering. The background is that the intrinsic returns a boolean value which is evaluated by a branch instruction of a (special) loop. The branch targets of this kind of loop are actually co...

...n J Jeon wrote: > > Hello, > > While I was trying to cross-compile Linux OMAP kernel with llvm, I have the > following error message. > > CC arch/arm/kernel/traps.o > cc1: > /home/wonjeon/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuild.cpp:5388: void > llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallSite): Assertion > `(OpInfo.ConstraintType == TargetLowering::C_RegisterClass || > OpInfo.ConstraintType == TargetLowering::C_Register) && "Unknown constraint > type!"' failed. > arch/arm/kernel/traps.c:748: internal compiler error:...

...n J Jeon wrote: > Hello, > > While I was trying to cross-compile Linux OMAP kernel with llvm, I > have the following error message. > > CC arch/arm/kernel/traps.o > cc1: /home/wonjeon/llvm/lib/CodeGen/SelectionDAG/ > SelectionDAGBuild.cpp:5388: void > llvm::SelectionDAGLowering::visitInlineAsm(llvm::CallSite): > Assertion `(OpInfo.ConstraintType == TargetLowering::C_RegisterClass > || OpInfo.ConstraintType == TargetLowering::C_Register) && "Unknown > constraint type!"' failed. > arch/arm/kernel/traps.c:748: internal compiler...