<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 28, 2020 at 12:07 PM Johannes Doerfert <<a href="mailto:johannesdoerfert@gmail.com">johannesdoerfert@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">[I removed all but the data layout question, that is an important topic]<br>
On 7/28/20 1:03 PM, Mehdi AMINI wrote:<br>
 > TL;DR<br>
 >> -----<br>
 >><br>
 >> Let's allow to merge to LLVM-IR modules for different targets (with<br>
 >> compatible data layouts) into a single LLVM-IR module to facilitate<br>
 >> host-device code optimizations.<br>
 >><br>
 ><br>
 > I think the main question I have is with respect to this limitation <br>
on the<br>
 > datalayout: isn't it too limiting in practice?<br>
 > I understand that this is much easier to implement in LLVM today, but it<br>
 > may get us into a fairly limited place in terms of what can be <br>
supported in<br>
 > the future.<br>
 > Have you looked into what would it take to have heterogeneous modules <br>
that<br>
 > have their own DL?<br>
<br>
<br>
Let me share some thoughts on the data layouts situation, not all of <br>
which are<br>
fully matured but I guess we have to start somewhere:<br>
<br>
If we look at the host-device interface there has to be some agreement<br>
on parts of the datalayout, namely what the data looks like the host<br>
sends over and expects back. If I'm not mistaken, GPUs will match the<br>
host in things like padding, endianness, etc. because you cannot<br>
translate things "on the fly". That said, here might be additional<br>
"address spaces" on either side that the other one is not matching/aware<br>
of. Long story short, I think host & device need to, and in practice do,<br>
agree on the data layout of the address space they use to communicate.<br>
<br>
The above is for me a strong hint that we could use address spaces to<br>
identify/distinguish differences when we link the modules. However,<br>
there might be the case that this is not sufficient, e.g., if the<br>
default alloca address space differs. In that case I don't see a reason<br>
to not pull the same "trick" as with the triple. We can specify<br>
additional data layouts, one per device, and if you retrieve the data<br>
layout, or triple, you need to pass a global symbol as a "anchor". For<br>
all intraprocedural passes this should be sufficient as they are only<br>
interested in the DL and triple of the function they look at. For IPOs<br>
we have to distinguish the ones that know about the host-device calls<br>
and the ones that don't. We might have to teach all of them about these<br>
calls but as long as they are callbacks through a driver routine I don't<br>
even think we need to.<br>
<br>
I'm curious if you or others see an immediate problem with both a device<br>
specific DL and triple (optionally) associated with every global symbol.<br></blockquote><div><br></div><div>Having a triple/DL per global symbols would likely solve everything, I didn't get from your original email that this was considered.</div><div></div><div>If I understand correctly what you're describing, the DL on the Module would be a "default" and we'd need to make the DL/triple APIs on the Module "private" to force queries to go through an API on GlobalValue to get the DL/triple?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
<br>
~ Johannes<br>
<br>
</blockquote></div></div></div>