similar to: [LLVMdev] help: about how to use tblgen to constraint operand.

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

I define a pattern to move two 32bits gpr to 64bits fpr. like arm instructure fmdrr. But I need to use an even/odd register pair to save its 2 operands. I define in mytarget.td: myfmdrr: SDTypeProfile<1, 2, [SDTCisVT<0, f64>, SDTCisVT<1, i32>,     SDTCisSameAs<1, 2>]>; def my_fmdrr : ........... def myFMDRR : ....                       (outs FPR: $result), ins(GPR:

Hi, EveryOne: I am travelling CFG with MachineFunction. So I want to sure it. (Preccessors' Number) < MachineBasicBlock's Number < (Successors's Number), Is it really? best regards. ___________________________________________________________ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed...

On Dec 3, 2009, at 9:52 PM, 任坤 wrote: > Hi, EveryOne: > > I am travelling CFG with MachineFunction. So I want to sure it. > (Preccessors' Number) < MachineBasicBlock's Number < (Successors's Number), Is it really? > Hi 任坤, I can't say for sure, though I don't think we make assurances that this is the case. If you want to traverse the CFG, there should

Hi, I have ported LLC to a risc cpu. It can pass benchmark that I have at current. But I want do some optimization after register alloction by adjusting register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg. R4 is marked <kill> at MBB0. If I scan R4's

On Jan 14, 2010, at 6:39 PM, 任坤 wrote: > But I want do some optimization after register alloction by adjusting > register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg. You can also look at RegisterScavenging.cpp and MachineVerifier.cpp. They are doing the same

hi,      I am porting llvm to our embedded cpu. By my abi, long long type is aligned by 8 bytes. But now llvm-gcc frontend follows x86 abi, generate word-alignment LLVM-IR for va_arg().    In some degree, llvm-gcc frontend depends on targets. The best solution is llvm-gcc can create va_arg node, I can lower it at the backend.    Who can give a temporary solution to make frontend can create 8

Hi: I hope to cut all backedges of MachineFunction CFG, then topological sort MachineBasicBlocks. 1. MachineDominatorTree *domintree = new MachineDominatorTree(); domintree->runOnMachineFunction(mf); 2. Then travel mf one by one. When domintree->dominates(next,current) is true, there is a backedge from current node to next node. move this backedge form CFG. But I find A LOOP in

I am porting llvm-gcc frontend. We have ported GCC4.2 for our target. So I move *.h *.md and *.c to llvm-gcc.  I do not implement any LLVM MACRO, and use default action of llvm-gcc.  I get a new llvm-gcc for our target. But I get a bug. /******************************/ //#include <stdio.h> union MYunion {   unsigned char uc ;   int ui; } myunion; void vfu1(union MYunion  u) {     u.ui =

Hi 任坤, > void vfu1(union MYunion u) { > u.ui = 99; > } here u is passed by copy, so vfu1 has no externally visible effect. I think you meant: union MYunion *u > define void @vfu1(%struct.MYunion* byval align 4 %u) nounwind { Here "byval" means that a pointer to a temporary copy of u is being passed, not u itself. Thus any writes to the %u parameter have no effect

On Dec 3, 2009, at 9:52 PM, 任坤 wrote: > I am travelling CFG with MachineFunction. So I want to sure it. > (Preccessors' Number) < MachineBasicBlock's Number < (Successors's Number), Is it really? If the CFG contains loops, how could this be possible? Anyway, no you can't use MBB numbers for that. Perhaps you need the MachineDominatorTree analysis? Regards, /jakob

2010/1/25 任坤 <hbrenkun at yahoo.cn>: > Hi: > > I hope to cut all backedges of MachineFunction CFG, then topological sort MachineBasicBlocks. > > 1. MachineDominatorTree *domintree = new MachineDominatorTree(); > domintree->runOnMachineFunction(mf); > > 2. Then travel mf one by one. > When domintree->dominates(next,current) is true, there is a backedge

Dear, I am looking at the Instructions defined in the XXXXInstrInfo.td where I can see a def record defined like below def ADD8rr : I8rr<0x0, (outs GR8:$dst), (ins GR8:$src, GR8:$src2), "add.b\t{$src2, $dst}", [(set GR8:$dst, (*add *GR8:$src, GR8:$src2)), (implicit SRW)]>; Now here I would like the to

Ok, thank you, I will implement it then. As far as I see this optimization should be done in AArch64LoadStoreOptimizer, is it right? From: Eli Friedman [mailto:efriedma at quicinc.com] Sent: Thursday, November 21, 2019 11:55 PM To: Kosov Pavel <kosov.pavel at huawei.com>; LLVM Dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] [ARM] Peephole optimization ( instructions tst +

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

On 11/11/2017 12:44 PM, Amara Emerson wrote: > >> On Nov 10, 2017, at 10:04 PM, Aditya Nandakumar <proaditya at gmail.com >> <mailto:proaditya at gmail.com>> wrote: >>> >>> The current DAGCombine, being constructed on top of SDAG, has a kind >>> of built-in CSE and automatic DCE. How will things change, if >>> they'll change, in

Micah, Do you mean we should make GPR64 available to register allocator by calling addRegisterClass? addRegisterClass(MVT::i64, &GPR64RegClass) If we add register class GPR64, type legalization will stop expanding i64 operations because i64 is now a legal type. Then we will probably have to write lots of code to custom-lower unsupported 64-bit operations during legalization. Note that

> On Nov 10, 2017, at 10:19 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 11/10/2017 11:12 AM, Amara Emerson via llvm-dev wrote: >> Hi everyone, >> >> This RFC concerns the design and architecture of a generic machine instruction combiner/optimizer framework to be developed as part of the GISel pipeline. As we transition from