similar to: tablegen dag syntax question

I have posted a patch that switches the API to one that supports this (yet non-existent functionality) earlier: https://reviews.llvm.org/D24631 The comments from that were incorporated into the following RFC. Motivation: Certain targets feature "variable-sized" registers, i.e. a situation where the register size can be configured by a hardware switch. A common instruction set

----- Original Message ----- > From: "Tom Stellard" <tom at stellard.net> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, March 13, 2014 9:46:22 AM > Subject: Re: [LLVMdev] Be Careful with Positionally-Encoded Operands (AArch64, Mips, AMDGPU, etc.) > > On

Hello, Some of the backends seem to be combining positional and named operands when defining some instructions such that some of the positional operands overlap with some of the named operands. I suspect this is not intentional; here's an example: AArch64 has the following instruction definition: SMULHxxx { field bits<32> Inst = { 1, 0, 0, 1, 1, 0, 1, 1, 0, 1, 0, Rm{4}, Rm{3},

hi, Dear Evan Cheng: My cpu is i32 embeded CPU. I define pseudo register pair registers. In mytargetRegisterInfo.td: def T0: RegisterWithSubRegs<"t0",[R0,R1]>; ... def GPR64 : RegisterClass<"mytarget", [i64], 64, [T0, T1.....] In mytargetISelLowering.cpp: I define i1, i8 , i16 and i32 are legal. 1. I still have problem. I save my function return double  value in

On Feb 19, 2009, at 8:26 PM, 任坤 wrote: > hi, Dear Evan Cheng: > > My cpu is i32 embeded CPU. I define pseudo register pair registers. > > In mytargetRegisterInfo.td: > def T0: RegisterWithSubRegs<"t0",[R0,R1]>; > ... > def GPR64 : RegisterClass<"mytarget", [i64], 64, [T0, T1.....] > > In mytargetISelLowering.cpp: > I define i1, i8 ,

I try to define a register class def GPR64 : RegisterClass<"mytarget", [i64], 64, [T0, T1.....] to simulate even/odd pair of GPR32 register. Actually, I just use GPR64 as a temporary register. My CPU just support i32 Integer type directly. I use FDR to save f64. def FDR : RegisterClass<"mytarget", [f64], 64,[FD0, FD1, ....] When I move f64 to even/odd pair register, I

Dear Evan Chang: I register incorrect Register class for MVT::f64. I have fixed it. Thanks your advice. "-view-legalize-dags" is very good option. But I don't know why my LLC do not know " -view-legalize-type-dags" option. By the way, I use llvm 2.5 merged from llvm2.4. Best Regards, Ren Kun --- 09年3月31日，周二, Evan Cheng <echeng at apple.com> 写道： 发件人: Evan Cheng

Bill, your CentOS 5 RTL8110 page should probably be updated. I've confirmed that there's a newer r8169 driver in the kernel that works with the RTL8110. RealTek's web site now carries the new r8169 instead of the r1000. The newer driver fixed a problem I was having on one host so we should probably recommend it over the older r1000. I've updated my CentOS 4 page. Kirk Bocek

Could I get write access to http://wiki.centos.org/HardwareList/CentOS5/RealTek/r1000? There's a couple of things I'd like to copy over from my CentOS4 R1000 page. Wiki Name: kirkbocek Thanks, Kirk Bocek

Hi Jeroen, Sorry, I missed that. I tried the patch, and this program: #include <stdint.h> #define __remote __attribute__((address_space(1))) __remote int* A; __remote int* B; void vec_add(__remote int* __restrict a, __remote int* __restrict b, int n) { #pragma unroll 4 for(int i=0; i<n; ++i) { a[i] += b[i]; } } int main(int argc, char** argv) {

Hi, I have tagged the 3.6.1-rc1 so testing can begin. We can always use more testers, so if you are interested in helping, let me know. Instructions for validating an LLVM release can be found here: http://llvm.org/docs/ReleaseProcess.html Reminder: We are using 3.6.0 as our baseline for regression testing. Thanks, Tom

Hello: I'm having issues with my CentOS 5.1/Xen installation. If I run the xen-bridge, I seem to get flaky ethernet. By flaky I mean everything seems fine from the host machine, but if I attempt to contact the host machine from another remote machine (eg. my laptop which is on the same subnet as the xen machine, separated by 10 ft of cable and a router) I either get extremely high ping

Hi Jeroen, That's great! I was trying to use the patch, what's the latest version of the project we could apply it on? Hi Neil, That seems like what I can do as well! Do you happen to have some examples lying around? Maybe a pointer to the planned presentation, if that's okay? Thank you, Bandhav On Mon, Jun 22, 2020 at 1:55 AM Neil Henning <neil.henning at unity3d.com>

Hi, I would like to start a new porting of GlobalIsel for RISCV. An initial patch about GlobalIsel infrastructure for RISCV was ready now: https://reviews.llvm.org/D65219 There is another porting patch https://reviews.llvm.org/D41653 posted by Leslie Zhai at the end of 2017. I have checked with Leslie about the status of this patch.He has stopped developing it since some questions need be

I'd like to add a page for the Realtek r1000 NIC driver for the RTL8110SC (and others) chipset. This driver is not included in the kernel. I've previously posted to the general mail list: http://lists.centos.org/pipermail/centos/2007-February/075383.html I'm guessing this would go in the HardwareList section. Otherwise a page titled 'Realtek r1000 Driver' would work. my

Howdy, It appears that CentOS 5.2's support for the RTL8111B/C chip is incomplete. The wiki has some blanket statements regarding this support: http://wiki.centos.org/AdditionalResources/HardwareList/CentOS5/RealTek/r1000 http://wiki.centos.org/AdditionalResources/HardwareList/RealTekRTL8111b I could dive in an make the changes *I* think need to happen but I'd like to talk to people

Hello I've just been hit by one of the chipsets described at http://wiki.centos.org/HardwareList/RealTekRTL8111b. Because a) it does not work with the stock driver included in Centos 5.1 and b) I am very lazy and I do not like manually compiling modules each time a new kernel is installed (not to mention that I never forget anything, except for the important things which always go

# RFC: Atomic LL/SC loops in LLVM revisited ## Summary This proposal gives a brief overview of the challenges of lowering to LL/SC loops and details the approach I am taking for RISC-V. Beyond getting feedback on that work, my intention is to find consensus on moving other backends towards a similar approach and sharing common code where feasible. Scroll down to 'Questions' for a summary

> I've disassembled the failing MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4 and compared it to > the one from the LLVM 3.6.0 test runs. There's nothing obvious. We've removed some useless > 'addiu $sp,$sp,0', eliminated two (seemingly redundant) sign extends, and the addresses of > functions+data has changed slightly. I've investigated further and I'm

I'm confused about how to specify DAG patterns for a given instruction Here is an example for my target class ALU1_RR<bits<4> subOp, string asmstr, SDNode OpNode> : ALU_RR<subOp, asmstr, [(set GPR:$rD, (OpNode (i32 GPR:$rA), (i32 GPR:$rB)))]>; def ADD : ALU1_RR<0x0, "l.add", add>; The set operation simply creates a list. The add operation