search for: performdagcombin

Hello LLVM, If there are any, can someone please explain rules of thumb for when to do a PerformDAGCombine operation in ISelLowering vs. when to do a DAG to DAG transformation? I'm specifically thinking of an AND + SRL merge into a bit field extract type instruction. I see that the ARM target does this in DAG-to-DAG, but this is literally a combine of two instructions,so why not DAGCombine? Than...

...> or PreprocessISelDAG(), which is what I did on an out-of-tree backend to > turn add X, -C into sub X, C on selection time. This still lets all the > intermediate optimizations take advantage of the canonicalization. > > —escha Unaware of your proposal, I used the TargetLowering::PerformDAGCombine hook. Is there a reason to prefere PreprocessISelDAG ? -- Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150710/12e26aab/attachment.html>

...o specialise build_vector for the case when one of the operands is undefined. How do I describe this? This is looking for an analog of specialisations like: def : Pat <v2i32 (build_vector i32:$x, (i32 0)),...>; but for an undefined, rather than zero, value. I can work around my ignorance in performDAGCombine but would prefer to add to the existing pattern matching. Thanks, Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170507/1fcc13ea/attachment.html>

...ionally work around your operation legalizations in unexpected ways (i.e., transforming (fabs:f64 arg) to (bitconvert:f64 (and:i64 (bitconvert:i64 arg), 0x7fffffffffffffff))) (b) If you add new pseudo-instructions (i.e., target-specific nodes in your ISelLowering source), make sure you know how to PerformDAGCombine. If there's no possible way to do PerformDAGCombine on your new pseudo-instructions, see (a). (c) If at all possible, handle target-specific instruction selection, e.g., 64-bit loads or other speciality instruction selection, in your ISelDAGToDAG source. For example, CellSPU cannot lower 64-b...

...rhaps. I looked at the ARM target code with PatFrag for negated immediates but that approach doesn't seem possible with register operands, as I don't know what xform would operate on. With immediates you have a DAG node you can generate. Also, it does seem like this is a folding operation PerformDAGCombine() could do but that approach seems like it needs to modify the registerclass, or something similar, that would eventually get you to a PrintMethod that could insert the dash/negate in front of the operand. I didn't want to define a 'mirror' registerclass for my existing register set th...

How can I prevent some nodes from being combined in DAGCombine.cpp? Maybe what I want to do below doesn't follow the philosophy of LLVM, but I'd like to know if there is any way to avoid node from being combined. TargetLowering::PerformDAGCombine() is only called if DAGCombiner cannot combine a specific node. It seems that there is no chance to stop it from combining a node. I need the shuffle mask in the machine instruction but sometimes if a vector_shuffle can only return LHS or RHS, it's removed/combined so that I cannot match vect...

...arget code with PatFrag for negated immediates > but that approach doesn't seem possible with register operands, as I > don't know what xform would operate on. With immediates you have a DAG > node you can generate. > > Also, it does seem like this is a folding operation > PerformDAGCombine() could do but that approach seems like it needs to > modify the registerclass, or something similar, that would eventually > get you to a PrintMethod that could insert the dash/negate in front of > the operand. I didn't want to define a 'mirror' registerclass for my > exis...

...alizations in > unexpected ways (i.e., transforming (fabs:f64 arg) to > (bitconvert:f64 (and:i64 (bitconvert:i64 arg), 0x7fffffffffffffff))) > > (b) If you add new pseudo-instructions (i.e., target-specific nodes > in your ISelLowering source), make sure you know how to > PerformDAGCombine. If there's no possible way to do > PerformDAGCombine on your new pseudo-instructions, see (a). > > (c) If at all possible, handle target-specific instruction > selection, e.g., 64-bit loads or other speciality instruction > selection, in your ISelDAGToDAG source. For exam...

...ing like "LD A,L / RET".) That said, what is the correct way to implement ISD::TRUNCATE this in the backend, using the CPU's capability that truncating i16 to i8 is simply accessing an i16' register's subreg? Should this be handled in "LowerOperation" or in "PerformDAGCombine"? Or could this be done with a target-independent combine? Would returning true in "isTruncateFree" suffice? Is any lowering code needed at all? The X86 backend seems to do both, "setTargetDAGCombine(ISD::TRUNCATE)", but then also registering a lot of MVTs via "set...

...this type is peculiar enough that other backend owners upon trying to add more DAG combiner passes are likely to miss adding the special handling codes as they probably should. In that case it would be a better idea to handle the ppc_fp128 DAG combiner cases somewhere under llvm::PPCTargetLowering::PerformDAGCombine() instead of in the target-independent DAGCombiner.cpp, - Gao > > -Hal > > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > &g...

..., so far i have it working for cases (modulo many unknown bugs :) where the tail called function is a destination within the source file and frame pointer elimination is performed. i implemented it as a dagcombiner transformation running in post legalized phase within the X86TargetLowering::PerformDAGCombine(SDNode *N, DAGCombinerInfo &DCI). now to my problem: When tail calling a function pointer the register the function pointer was loaded to might be invalidated by the restored callee saved registers. ... movl 12(%esp), %esi << 12(%esp) contains the function pointer movl %...

I recently filed this bug: http://llvm.org/bugs/show_bug.cgi?id=8323 It's a dodgy one because you have to patch LLVM to demonstrate it. I suspect that the cause of the problem in that "bug" is that the peephole optimisation in PerformDAGCombine results in a Flag output from one node being used as input by two other nodes in the DAG, and the scheduler then can't cope with that. Is it, or should it be legal for a Flag output to be used as input by more than one other node? If it is legal, does it ever actually work, and, if not, is t...

...some target-specific combining. Look for calls to setTargetDAGCombine() for examples of this. For this case, the relevant nodes are all target-specific, so the DAG combiner will call the target-specific combining hook anyway. 1. Add the ARMISD::VCEQ etc. nodes to the switch in ARMTargetLowering::PerformDAGCombine. 2. Add a function to be called for those comparisons that checks if one operand is an ARMISD::VMOVIMM node with an immediate of zero. Note for future reference that the actual operand of VMOVIMM is an encoded value that represents one of the possible vector immediates for the "one register...

...t such a strategy due to the basic-block granularity of the SelectionDAG and lack of use information for GlobalAddress values. I was wondering whether anybody has looked into this sort of issue for an in-tree or out-of-tree backend, or had any thoughts on addressing it. The numbers for introducing performDAGCombine to the AArch64 backend certainly indicate that performing the combine is a net win (46KB reduction in .text size of chromium), but it would interesting to look at addressing cases where the combine is counterproductive. ## Appendix: example 1 For the following code snippet, folding the offset int...

Hi folks, me again, So, I want to implement a simple optimization in a NEON case I've seen these days, most as a matter of exercise, but it also simplifies (just a bit) the code generated. The case is simple: uint32x2_t x, res; res = vceq_u32(x, vcreate_u32(0)); This will generate the following code: ; zero d16 vmov.i32 d16, #0x0 ; load a

Dear all, I have been working on a new LLVM backend. Some instructions, like sub, can take an positive constante, encoded into 5 bits thus lower than 32, and a register, as operands. Unfortunately, DAGCombiner.cpp changes patterns like 'sub x, 5' into 'add x,-5'. Similarly, I found changes in some IR to IR passes, with no clear gain (at least not clear to me), and even penalty

Hi Vivek, You could work around this by creating a custom ISD node, e.g. MyTargetISD::MyLSHR, with the same type as the general ISD::LSHR. This custom node will then be ignored by the generic DAGCombiner. Convert ISD::LSHR to MyTargetISD::MyLSHR in DAGCombine, optimise it as you see fit, convert it back or lower it directly. I've done this for ISD::CONCAT_VECTORS to avoid an inconvenient

...ion. By 'combination of DAG nodes' I understand 'replacing a set of DAG nodes by an (usually smaller) set of DAG nodes, removing dead nodes and updating all the chains'. I'm using the setTargetDAGCombine(ISD::EXTRACT_VECTOR_ELT) and build the new LOAD_VECTOR_EXTRACT node in the PerformDAGCombine(). As per the following trace this work, t59 and params from t58 are merged into t72. During this combination, the chain from t59 to t58 has been merged from new t72 to t57, skipping over t58. So far, so good. My problem is that this node t58 is not removed from DAG. One reason could be that nod...

Hello, Arnold. > with the sentence i tried to express the question whether there is a > way to persuade the code generator to use another register to load (or > move) the function pointer to (right before the callee saved register > restore) but thinking a little further that's nonsense. Why don't define some special op for callee address and custom lower it? I really

On Mon, Nov 30, 2015 at 7:24 PM Gao, Yunzhong < yunzhong_gao at playstation.sony.com> wrote: > According to > http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html, > "The high-order double-precision value (the one that comes first in > storage) must have the larger magnitude." > > So the order of the two doubles in your fp128 is not affected by the