llvm dev - Mar 2021 - Understanding TargetLowering::LowerCall

On Mon, 22 Mar 2021 at 07:36, Zhang via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> For CallSites that contains a GlobalValue as one of the arguments, where
exactly does the lowering from GlobalAddress to iPTR took place?.
It's generally no different for a callsite than any other GlobalValue
user. The generic SelectionDAGBuilder code will create a GlobalAddress
SDNode with iPTR type because the type of a GlobalValue is actually a
pointer to the type of the underlying object.

The call lowering code will get this iPTR node, and may well decide to
pass it to the callee in a register.

As for the GlobalAddress node, that goes through normal lowering to a
target-specific instruction sequence to materialize the address of the
global object. Often this is via custom C++ in LegalizeDAG (i.e.
`setOperationAction(ISD::GlobalValue, MVT::i64, Custom)`).

Cheers.

Tim.

Hi Tim,
I had similar problem a couple of weeks ago but I somehow circumvented it.
However, I dont understand much from the description. Can you please
provide some example of backend which does this? probably what functions in
X86 backend handle this lowering? If I look at the code I will be able to
understand more clearly.

On Mon, Mar 22, 2021, 3:27 PM Tim Northover via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Mon, 22 Mar 2021 at 07:36, Zhang via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > For CallSites that contains a GlobalValue as one of the arguments,
where
> exactly does the lowering from GlobalAddress to iPTR took place?.
>
> It's generally no different for a callsite than any other GlobalValue
> user. The generic SelectionDAGBuilder code will create a GlobalAddress
> SDNode with iPTR type because the type of a GlobalValue is actually a
> pointer to the type of the underlying object.
>
> The call lowering code will get this iPTR node, and may well decide to
> pass it to the callee in a register.
>
> As for the GlobalAddress node, that goes through normal lowering to a
> target-specific instruction sequence to materialize the address of the
> global object. Often this is via custom C++ in LegalizeDAG (i.e.
> `setOperationAction(ISD::GlobalValue, MVT::i64, Custom)`).
>
> Cheers.
>
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210322/7ce5ae8b/attachment.html>

Thanks Tim.
One more thing I'm still not quite clear is how to differ GlobalAddress from
registers when selection instructions.
Say the Initial DAG is :
```
load<(dereferenceable load 4 from @gv)&gt; t0,
TargetGlobalAddress:i64<i32* @gv&gt; 0, undef:i64
```


And in our ISA we have:
```
LOAD_RM reg1,reg2 which basically means reg1 = *reg2
```


However when I use [(set (i32 GP32:$dst),(load GP64:$reg))] as the pattern for
this ISA. the aforementioned DAGNode got matched as well.
How do I prevent such nodes from being matched since in our ISA GlobalAddress
requires custom lowering
&nbsp;
&nbsp;
------------------&nbsp;Original&nbsp;------------------
From: &nbsp;"Tim Northover"<t.p.northover at gmail.com&gt;;
Date: &nbsp;Mon, Mar 22, 2021 05:57 PM
To: &nbsp;"Zhang"<admin at mayuyu.io&gt;; 
Cc: &nbsp;"llvm-dev"<llvm-dev at lists.llvm.org&gt;; 
Subject: &nbsp;Re: [llvm-dev] Understanding TargetLowering::LowerCall

&nbsp;

On Mon, 22 Mar 2021 at 07:36, Zhang via llvm-dev
<llvm-dev at lists.llvm.org&gt; wrote:
&gt; For CallSites that contains a GlobalValue as one of the arguments,
where exactly does the lowering from GlobalAddress to iPTR took place?.

It's generally no different for a callsite than any other GlobalValue
user. The generic SelectionDAGBuilder code will create a GlobalAddress
SDNode with iPTR type because the type of a GlobalValue is actually a
pointer to the type of the underlying object.

The call lowering code will get this iPTR node, and may well decide to
pass it to the callee in a register.

As for the GlobalAddress node, that goes through normal lowering to a
target-specific instruction sequence to materialize the address of the
global object. Often this is via custom C++ in LegalizeDAG (i.e.
`setOperationAction(ISD::GlobalValue, MVT::i64, Custom)`).

Cheers.

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210323/1b8640d9/attachment.html>