search for: 0b01

Hello, while testing trivial functions in my backend i noticed a suboptimal way of assigning regs that had the following pattern, consider the following function: typedef unsigned short t; t foo(t a, t b) { t a4 = b^a^18; return a4; } Argument "a" is passed in R15:R14 and argument "b" is passed in R13:R12, the return value is stored in R15:R14. Producing 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", ".f32.f16\t$Sd, $Sm", []>, Requires<[HasFP16]>, Sched<[WriteFPCVT]>; def : FP16Pat<(f16_to_fp GPR:$a), (VCVTBHS (COPY_TO_...

...gt; > > > The 0x prefix might add to the confusion here. It is really just two > > bits, no? > > Ouch. Yes I meant 0b. Thanks! 0b00, 0b10 are written by device? I suppose device can only clear high bit, can keep low bit no change. Then the value written by device can be either 0b01 or 0b00, but 0b10 means to set high bit, no? > > > > each time driver writes out a descriptor, it must make sure that the > > > high bit in OWNER changes. > > > > > > each time device writes out a descriptor, it must make sure that the > > > high bi...

...gt; > > > The 0x prefix might add to the confusion here. It is really just two > > bits, no? > > Ouch. Yes I meant 0b. Thanks! 0b00, 0b10 are written by device? I suppose device can only clear high bit, can keep low bit no change. Then the value written by device can be either 0b01 or 0b00, but 0b10 means to set high bit, no? > > > > each time driver writes out a descriptor, it must make sure that the > > > high bit in OWNER changes. > > > > > > each time device writes out a descriptor, it must make sure that the > > > high bi...

Indeed, i've marked it as commutable: let isCommutable = 1, isTwoAddress = 1 in def XORRdRr : FRdRr<0b0010, 0b01, (outs GPR8:$dst), (ins GPR8:$src1, GPR8:$src2), "xor\t$dst, $src2", [(set GPR8:$dst, (xor GPR8:$src1, GPR8:$src2))]>; -------------- next part -------------- An HTML attachment was scrubbed... URL: <htt...

Hello > and as the return value. Is this a missed optimization from LLVM or did i > miss something out? > Changing the register allocation order didnt work. What are the patterns for xor / mov ? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...containing the ins and outs dags, using if(eq()) extensively, so that the multiclass template for the instructions is a single line. Code follows (probably not correct due to name mangling). class IO_MultSrc<bits<2> op0Type, RegisterClass Src0RC> { dag insDefault = !if(!eq(op0Type, 0b01), (ins SpecialReg:$dst, Src0RC:$a), (ins Src0RC:$a)); ... } multiclass MultSrc1Spec<bits<5> subOpcode, bits<2> op0t, string opcodeStr, RegisterClass RegType> { def _allspecial: MultSrcOneDestInst<subOpcode, op0t, 0b00,...

...[(set HPR:$Sd, (fadd HPR:$Sn, HPR:$Sm))]>, // <~~~ new match rule using HPR This is straightforward business so far, but I already learned the hard way that the conversion are the tricky ones, so I repeat this for an f16 -> f32 upconvert: def VCVTBHS: ASuI<0b11101, 0b11, 0b0010, 0b01, 0, (outs SPR:$Sd), (ins HPR:$Sm), IIC_fpCVTSH, "vcvtb", ".f32.f16\t$Sd, $Sm", [(set SPR:$Sd, (fpextend HPR:$Sm))]>, // <~~~~ new match rule using HPR and SPR Requires<[HasFP16]>, Sched<[WriteFPC...

Hi, I am a very new to ruby on rails so please forgive me if someone has asked this before. I need to make a form with many checkboxes. Sometime ago I was using Coldfusion and I chanced upon this great article on how to store flags using binary numbers. http://cfdj.sys-con.com/read/41674.htm Just wondering if there is something similar in RubyOnRails that I can learn from and use. That

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.

...= 0b11 | ballot 1 = 0b11 skipped | ballot 2 = 0b10 ballot 1 = 0b11 | ballot 1 = 0b11 skipped | ballot 2 = 0b10 Now, contrast this with the execution trace that programmers would expect for the second example: thread 0 | thread 1 ballot 1 = 0b11 | ballot 1 = 0b11 ballot 1 = 0b01 | skipped skipped | ballot 2 = 0b10 skipped | ballot 1 = 0b10 skipped | ballot 2 = 0b10 Nicolai's proposal solves this by having the frontend emit a merge intrinsic before the i++ is emitted. This prevents the jump forwarding from occurring. > > About the CSE, wh...

On Sun, Oct 01, 2017 at 04:08:29AM +0000, Michael S. Tsirkin wrote: >On Thu, Sep 28, 2017 at 09:44:35AM +0000, Liang, Cunming wrote: >> >> Get it now. Please correct me if I missing something. >> >> >> Flags status hints, >> >> - DESC_DRIVER only: driver owns the descriptor w/o available info ready for device to use >> >> - DESC_DRIVER |

On Sun, Oct 01, 2017 at 04:08:29AM +0000, Michael S. Tsirkin wrote: >On Thu, Sep 28, 2017 at 09:44:35AM +0000, Liang, Cunming wrote: >> >> Get it now. Please correct me if I missing something. >> >> >> Flags status hints, >> >> - DESC_DRIVER only: driver owns the descriptor w/o available info ready for device to use >> >> - DESC_DRIVER |

Thanks. I saw the header comments but it wasn’t clear to me what the difference between those concepts is? My slightly vague understanding is IsDef means that the register specified by this operand is set by the machine instruction. So I understand that to mean the MO will override that register? Also things like early clobber, perhaps there is another document that clarifies some of these

...| ballot 2 = 0b10 > ballot 1 = 0b11 | ballot 1 = 0b11 > skipped | ballot 2 = 0b10 > > Now, contrast this with the execution trace that programmers would expect for the second example: > > thread 0 | thread 1 > ballot 1 = 0b11 | ballot 1 = 0b11 > ballot 1 = 0b01 | skipped > skipped | ballot 2 = 0b10 > skipped | ballot 1 = 0b10 > skipped | ballot 2 = 0b10 > > Nicolai's proposal solves this by having the frontend emit a merge intrinsic before the i++ is emitted. This prevents the jump forwarding from occurring. >...

...b11 | ballot 1 = 0b11 > > skipped | ballot 2 = 0b10 > > > > Now, contrast this with the execution trace that programmers would > expect for the second example: > > > > thread 0 | thread 1 > > ballot 1 = 0b11 | ballot 1 = 0b11 > > ballot 1 = 0b01 | skipped > > skipped | ballot 2 = 0b10 > > skipped | ballot 1 = 0b10 > > skipped | ballot 2 = 0b10 > > > > Nicolai's proposal solves this by having the frontend emit a merge > intrinsic before the i++ is emitted. This prevents the jump forw...

...b11 | ballot 1 = 0b11 > > skipped | ballot 2 = 0b10 > > > > Now, contrast this with the execution trace that programmers would > expect for the second example: > > > > thread 0 | thread 1 > > ballot 1 = 0b11 | ballot 1 = 0b11 > > ballot 1 = 0b01 | skipped > > skipped | ballot 2 = 0b10 > > skipped | ballot 1 = 0b10 > > skipped | ballot 2 = 0b10 > > > > Nicolai's proposal solves this by having the frontend emit a merge > intrinsic before the i++ is emitted. This prevents the jump forw...

...b11 | ballot 1 = 0b11 > > skipped | ballot 2 = 0b10 > > > > Now, contrast this with the execution trace that programmers would > expect for the second example: > > > > thread 0 | thread 1 > > ballot 1 = 0b11 | ballot 1 = 0b11 > > ballot 1 = 0b01 | skipped > > skipped | ballot 2 = 0b10 > > skipped | ballot 1 = 0b10 > > skipped | ballot 2 = 0b10 > > > > Nicolai's proposal solves this by having the frontend emit a merge > intrinsic before the i++ is emitted. This prevents the jump forw...

...ipped        | ballot 2 = 0b10 > > > > Now, contrast this with the execution trace that programmers > would expect for the second example: > > > > thread 0        | thread 1 > > ballot 1 = 0b11 | ballot 1 = 0b11 > > ballot 1 = 0b01 | skipped > > skipped        | ballot 2 = 0b10 > > skipped        | ballot 1 = 0b10 > > skipped        | ballot 2 = 0b10 > > > > Nicolai's proposal solves this by having the frontend emit a > merge intrinsic before the i++ is emitted...

...; > > > > > Now, contrast this with the execution trace that programmers > > would expect for the second example: > > > > > > thread 0 | thread 1 > > > ballot 1 = 0b11 | ballot 1 = 0b11 > > > ballot 1 = 0b01 | skipped > > > skipped | ballot 2 = 0b10 > > > skipped | ballot 1 = 0b10 > > > skipped | ballot 2 = 0b10 > > > > > > Nicolai's proposal solves this by having the frontend emit a > > merge intrin...