search for: sext_inreg

...e the operand of a low-part register, and then sign extends into the full register.I find that there is no way to use for example (set RC:$srsc, sext($src, 16)), or in any other way use a sext operator to perform this on one register. It would be neat to be able to do this somehow. When I define a sext_inreg instruction, LLVM does not match the sext node in the DAG with this, unfortunately. How is feats like this supposed to be done? Right now it seems that I need to do a custom lowering impelementation to replace the sext-SDValue with a subgraph with a 32bit virtual register, a copy to the low subreg...

...e a correct pattern for this. It is essential to know the original type of the shift amount. The fact it was i32 means that it's safe to select SLLW in this case (as a shift amount > 31 would be undefined behaviour). It's tempting to write a pattern like the following: def : Pat<(sext_inreg (shl GPR:$rs1, GPR:$rs2), i32), (SLLW GPR:$rs1, GPR:$rs2)>; But as Eli Friedman kindly pointed out, the `sext_inreg` node can be generated in cases other than i32 to i64 widening. e.g. define i64 @tricky_shl(i64 %a, i64 %b) { %1 = shl i64 %a, %b %2 = shl i64 %1, 3...

...re's also likely to be cases where you want to calculate the demanded bits > > in order to determine if e.g. a W-suffixed instruction can be selected for > > `(somoeop (zexti32 GPR:$rs1), (zexti32 GPR:$rs2))`. This is easy to match if > > the SelectionDAG contains an explicit `sext_inreg` of the result. But if not, > > you'd need to check whether the upper 32 bits are actually demanded or not. > > Could you describe more specifically where this matters? I would guess > the W-suffixed instructions aren't actually any cheaper, in general, > than non-W-suffi...

Hello, in some operations there is a ty2 type, for example in truncate. What is the most right way to get it ? I have seen some EVT types, but this is connected to DAG... and I don't believe that there is no easy way to get ty2 with one call function. -------------- next part -------------- An HTML attachment was scrubbed... URL:

...es action for vectors that corresponds to "promote" on scalars. In this case, since X86 supports VSETCC, the 4 x i1 SETCC should "vector promote" to a VSETCC node with a 4xi32 result, the and should vector promote to 4xi32, and the sext should vector promote as a vector sext_inreg. I don't think that implementing this is particularly hard, but I have plenty of other things I'm working on right now. Is anyone else interested in working on this? -Chris

You are welcome. I changed the pattern, the same old error pop up again, crash in the same place. Type set is empty for each HW mode: possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records). vtInt: &nbsp; (vt:{ *:[Other] }) UNREACHABLE executed at /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824!

Hi, We are now about halfway between the 3.4 and 3.5 releases, and I would like to start preparing for a 3.4.1 release. Here is my proposed release schedule: Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. April 9 - April 18: Testing Phase April 18: 3.4.1 Release How you can help: - If you have any bug fixes you think should be included to 3.4.1, send me an

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

..."unhandled MERGE_VALUES"); - ExpandOp(Op.getOperand(0), Lo, Hi); - // Remember that we legalized the chain. - AddLegalizedOperand(Op.getValue(1), LegalizeOp(Op.getOperand(1))); - break; - - case ISD::SIGN_EXTEND_INREG: - ExpandOp(Node->getOperand(0), Lo, Hi); - // sext_inreg the low part if needed. - Lo = DAG.getNode(ISD::SIGN_EXTEND_INREG, dl, NVT, Lo, Node->getOperand(1)); - - // The high part gets the sign extension from the lo-part. This handles - // things like sextinreg V:i64 from i8. - Hi = DAG.getNode(ISD::SRA, dl, NVT, Lo, -...