<div><font>Thanks Tim.</font></div><div>One more thing I'm still not quite clear is how to differ GlobalAddress from registers when selection instructions.</div><div>Say the Initial DAG is :</div><div>```</div><div>load<(dereferenceable load 4 from @gv)> t0, TargetGlobalAddress:i64<i32* @gv> 0, undef:i64</div><div>```</div><div><br></div><div>And in our ISA we have:</div><div>```</div><div>LOAD_RM reg1,reg2 which basically means reg1 = *reg2</div><div>```</div><div><br></div><div>However when I use [(set (i32 GP32:$dst),(load GP64:$reg))] as the pattern for this ISA. the aforementioned DAGNode got matched as well.</div><div>How do I prevent such nodes from being matched since in our ISA GlobalAddress requires custom lowering</div><div><includetail><div> </div><div> </div><div style="font:Verdana normal 14px;color:#000;"><div style="FONT-SIZE: 12px;FONT-FAMILY: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="FONT-SIZE: 12px;background:#efefef;padding:8px;"><div id="menu_sender"><b>From: </b> "Tim Northover"<t.p.northover@gmail.com>;</div><div><b>Date: </b> Mon, Mar 22, 2021 05:57 PM</div><div><b>To: </b> "Zhang"<admin@mayuyu.io>; <wbr></div><div><b>Cc: </b> "llvm-dev"<llvm-dev@lists.llvm.org>; <wbr></div><div><b>Subject: </b> Re: [llvm-dev] Understanding TargetLowering::LowerCall</div></div><div> </div><div style="position:relative;"><div id="tmpcontent_res"></div>On Mon, 22 Mar 2021 at 07:36, Zhang via llvm-dev<br><llvm-dev@lists.llvm.org> wrote:<br>> For CallSites that contains a GlobalValue as one of the arguments, where exactly does the lowering from GlobalAddress to iPTR took place?.<br><br>It's generally no different for a callsite than any other GlobalValue<br>user. The generic SelectionDAGBuilder code will create a GlobalAddress<br>SDNode with iPTR type because the type of a GlobalValue is actually a<br>pointer to the type of the underlying object.<br><br>The call lowering code will get this iPTR node, and may well decide to<br>pass it to the callee in a register.<br><br>As for the GlobalAddress node, that goes through normal lowering to a<br>target-specific instruction sequence to materialize the address of the<br>global object. Often this is via custom C++ in LegalizeDAG (i.e.<br>`setOperationAction(ISD::GlobalValue, MVT::i64, Custom)`).<br><br>Cheers.<br><br>Tim.<br></div></div><!--<![endif]--></includetail></div>