similar to: Conditional Register Assignment based on the no of loop iterations

Displaying 9 results from an estimated 9 matches similar to: "Conditional Register Assignment based on the no of loop iterations"

2017 Jul 10
2
Conditional Register Assignment based on the no of loop iterations
Here basically my problem is vector width since i have used v64i32 in my backend. now if vector width=64. i want the Reg_B class registers to be assigned and if vector width=2048 i want Reg_A registers to be assigned to instruction. Should i incorporate the solution in lowering stage? some thing like; addRegisterClass(MVT::v2048i32, &X86::Reg_B);
2017 Jul 11
2
error: In anonymous_4820: Unrecognized node 'VRR128'!
hello, i need to use v32i32 and v32f32 in store instructions. I defined my register as; def VRR128 : RegisterClass<"X86", [v32i32, v32f32], 1024, (add R_0_V_0, R_1_V_0, R_2_V_0)>; def STORE_DWORD : I<0x70, MRMDestMem, (outs), (ins i2048mem:$dst, VRR128:$src), "STORE_DWORD\t{$src, $dst|$dst, $src}",
2017 Jul 11
2
error: In anonymous_4820: Unrecognized node 'VRR128'!
Thank You. How to do the same for add please see the following; it gives duplication error. def VADD : I<0x0E, MRMDestReg, (outs VRR128:$dst), (ins VRR128:$src1, VRR128:$src2),"VADD\t{$src1, $src2, $dst|$dst, $src1, $src2}", [(set VRR128:$dst, (add VRR128:$src1, VRR128:$src2))]>, TA; def : Pat<(add VRR128:$src1, VRR128:$src2), (VADD VRPIM128:$src1, VRPIM128:$src2)>;
2017 Jul 11
2
Using new types v32f32, v32f64 in llvm backend not possible
Thank you so much. it run fine. Can you please resolve following issue; I now have support for v2048i32 but my backend supports v64i32 so ultimately v2048i32 needs to be split into 32 v64i32 instructions. the only difference between 2 is if its orginally v2048i32 i want my registers assignment from REG_A set. if its v64i32 originally, then i want registers from set REG_B. How to accomplish
2017 Jul 11
2
error: In anonymous_4820: Unrecognized node 'VRR128'!
Thank You. But can we use same register class for fadd as well, is this instruction correct? def VFADD : I<0x0E, MRMDestReg, (outs VRR128:$dst), (ins VRR128:$src1, VRR128:$src2),"VFADD\t{$src1, $src2, $dst|$dst, $src1, $src2}", [(set VRR128:$dst, (fadd VRR128:$src1, VRR128:$src2))]>, TA; On Tue, Jul 11, 2017 at 9:00 PM, Craig Topper <craig.topper at gmail.com> wrote: >
2017 Jul 12
2
Using new types v32f32, v32f64 in llvm backend not possible
I would be very grateful if you specify whether there is some way to allocate registers (different order) / from different register sets to the same instruction based on the vector width/ no of iterations. I have tried several alternatives but could not succeed. Also I have asked this question many times but no one responds. Is there something wrong with this?? Kindly guide me. Thank You On
2012 Aug 07
6
Big Bug:Time in VM running on xen goes slower
Dear all: I have found a big bug on xen concerning time virtualization. Please let me show you the whole process: 1 Phenomenon when I run a JVM based program in IE browser in my Virtual Machine, I have found clearly that time at the right bottom corner in my VM gets more slower and slower. I studied the bug deeply, and found something below. 2 Xen vmx_vmexit_handler --> ......... -->
2017 Jul 11
2
Using new types v32f32, v32f64 in llvm backend not possible
Hello, i want to work with these types v32f32, v32f64.... in llvm which are undefined in the backend? But v32i32, v32i64 are already defined so i am able to use these. but for other types such as v32f32, v32f64 although i have defined them appropriately in all the files like machinevaluetype.h, valuetypes.cpp etc. i have checked it many times but still getting the following error when build in
2013 Jan 23
10
[PATCH 0/6] x86/HVM: miscellaneous RTC emulation adjustments
Finally I got around to breaking up the similarly named monolithic patch that caused a regression shortly before the 4.2 release and got therefore reverted. This series consists of the broken up pieces that - according to my testing - don''t expose the reported lockup; the 7th will need debugging to understand what''s wrong there. 1: use RTC_* names instead of literal numbers 2: