similar to: COPYs between register classes

Hi, we are in the midst of an interesting work that begun with setting 'guessInstructionProperties = 0' in the SystemZ backend. We have found this to be useful, and discovered many instructions where the hasSideEffects flag was incorrectly set while it actually shouldn't. The attached patch and test case triggers an assert in TwoAddress.  (bin/llc ./tc_TwoAddr_crash.ll

Hi, I wonder if anyone has any comment on a patch like: diff --git a/lib/CodeGen/SelectionDAG/InstrEmitter.cpp b/lib/CodeGen/SelectionDAG/InstrEmitter.cpp index 65ee3816f84..4780f6f0e59 100644 --- a/lib/CodeGen/SelectionDAG/InstrEmitter.cpp +++ b/lib/CodeGen/SelectionDAG/InstrEmitter.cpp @@ -243,18 +243,21 @@ void InstrEmitter::CreateVirtualRegisters(SDNode *Node,      if (!VRBase &&

Hi, SystemZ supports @llvm.ctlz.i64() natively with a single instruction (FLOGR), and lesser bitwidth versions of the intrinsic are promoted to i64. For some reason, this leads to unfolded additions of constants as shown below: This function: define i16 @fun(i16 %arg) {   %1 = tail call i16 @llvm.ctlz.i16(i16 %arg, i1 false)   ret i16 %1 } ,gives this optimized DAG as input to instruction

Thanks a lot for the suggestions! I will look into using vld1/vst1, sounds good. I am custom lowering the bitcasts, that's now the only place where FP_TO_FP16 and FP16_TO_FP nodes are created to avoid inefficient code generation. I will double check if I can't achieve the same without using these nodes (because I really would like to get completely rid of them). Cheers, Sjoerd.

I would like to revive this thread, as I am struggling a lot with the FP16 implementation in the ARM backend. My implementation in https://reviews.llvm.org/D38315 is finished (except one case), but a more robust alternative implementation was suggested. One can indeed argue that my current implementation is a bit fragile, because it involves manually patching up the isel dags for a few cases. The

Hi Sjoerd, For ISel, I think having a separate register class will give you less headache. I wondering if you could get away with not touching the instructions descriptions at all, instead defining external pattens for the FullFP16 case, like so: def VCVTBHS: ASuI<0b11101, 0b11, 0b0010, 0b01, 0, (outs SPR:$Sd), (ins SPR:$Sm), IIC_fpCVTSH, "vcvtb",

Hi Jonas, Thanks for bringing that up. > On Nov 30, 2017, at 4:04 AM, Jonas Paulsson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > we are in the midst of an interesting work that begun with setting 'guessInstructionProperties = 0' in the SystemZ backend. We have found this to be useful, and discovered many instructions where the hasSideEffects flag

Jakob Stoklund Olesen <jolesen at apple.com> writes: > These sub-registers are special, they are only mentioned here: > > let CompositeIndices = [(sub_ss), (sub_sd)] in { > def XMM0: Register<"xmm0">, DwarfRegNum<[17, 21, 21]>; > def XMM1: Register<"xmm1">, DwarfRegNum<[18, 22, 22]>; > ... I'm confused. Below you

All, I've been trying to simplify the way LLVM models sub-register relationships a bit, and the X86 sub_ss and sub_sd sub-register indices are getting in the way. I want to get rid of them. These sub-registers are special, they are only mentioned here: let CompositeIndices = [(sub_ss), (sub_sd)] in { def XMM0: Register<"xmm0">, DwarfRegNum<[17, 21, 21]>; def

So there's a DAG that looks like this in the debug output: Selecting: t3: ch,glue = CopyToReg t0, Register:i16 %R5, Constant:i16<127> In the instruction selection phase, what pattern would that match? I've constructed this so far: (??? REG16:$dst, i16imm:$src) but the problem is, I can't determine what to use as ???. There is an ISD::CopyToReg enum value, but I don't

Hi all, Our target does not have native support for 64-bit integers, so we rely on library calls for certain operations (like sdiv). We recently ran into a problem where these operations that are expanded to library calls aren't maintaining the proper ordering in relation to other chains in the DAG. The following snippet of a DAG demonstrates the problem. t0: ch = EntryToken t2:

Hmm, okay. Then what's the problem being reported here? I'm not sure what I'm supposed to do with "LLVM ERROR: Cannot select: t1: i16 = Constant<127>".BTW, the function is: ; ModuleID = 'return.c' source_filename = "return.c" target datalayout = "E-m:e-p:16:16:16-i1:16:16-i8:16:16-i16:16:16-i32:16:16-i64:16:16-S16-n16" target triple =

I have a CopyToReg that is moving a 16bit reg to a 32bit reg, it's currently being mapped out as a simple mov (not an ext), I would like to change that to an ext. It seemed that the SelDAG was the easiest and cleanest way to do this. I can change the mov to an extension MI in the .td file; however, I can't tell at that point whether it's a sext or a zext, so it seemed the SelDAG was

Well, that's the thing: I thought that was CopyToReg. I don't know what the name of the node is to load one value into a register, so I don't know how to construct such a pattern. On Sat, Nov 4, 2017 at 9:23 PM Craig Topper <craig.topper at gmail.com> wrote: > Do you have a pattern for loading an i16 immediate into a 16-bit register? > > ~Craig > > On Sat, Nov 4,

So if I first create the value in an entry BB and then build a CopyToReg but then I have to read it in a BB that loops back to itself, with it's own CopyToReg at the end, then I have two CopyToReg nodes for the same value. In this case, I need to create 3 virt regs, 1 for each CopyToReg and a third for the CopyFromReg in the beginning of the loop BB, right? And then I need to build a PHI

On Thu, Feb 18, 2016 at 11:34 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 2/18/2016 1:32 PM, Rail Shafigulin wrote: > >> I think this is where I'm loosing the "thread". Based on what I'm seeing >> SET_FLAG has three operands, the first of which is a CopyFromReg. So how >> come the pattern is SET_FLAG %vreg5, 3, 20 and not

Hi Tim, Tim Northover-2 wrote > The code used for DIV is around X86ISelDAGToDAG.cpp:2415, but from a > glance the key points seem to be: > 1. use the second result of getCopyToReg (i.e. SDValue(setIdNode, 1)) > in the RDMSR node. > 2. Give your RDMSR node type MVT::Glue instead of MVT::Other I tried doing what you said, and the DAG looks like how I think it supposed to look like

So if I create a value with a DAG.getUndef(myVT); call during instruction legalization, how can I access that value as input in another BB/DAG (also during instruction legalization) without worrying about live-ins and/or phi nodes? Can I create a single virtual register and build both a CopyToReg and a CopyFromReg node with it? I assumed that would break SSA. Perhaps I should have said that what

Setting the ISD::ROTL to Expand doesn't work? (via SetOperation) You could also do a Custom hook if that's what you're looking for. On Thu, Nov 3, 2016 at 5:12 PM, Phil Tomson <phil.a.tomson at gmail.com> wrote: > ... or perhaps to rephrase: > > In 3.9 it seems to be doing a smaller combine much sooner, whereas in 3.6 > it deferred that till later in the

Is there any way to get it to delay this optimization where it goes from this: Initial selection DAG: BB#0 'bclr64:entry' SelectionDAG has 14 nodes: t0: ch = EntryToken t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0 t4: i64,ch = CopyFromReg t0, Register:i64 %vreg1 t6: i64 = sub t4, Constant:i64<1> t7: i64 = shl Constant:i64<1>, t6