<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 16, 2019 at 1:28 AM Tim Northover via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Christoffer,<br>
<br>
On Mon, 16 Dec 2019 at 00:03, Christoffer Lernö via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Aside from using the new methods (e.g. LLVMBuildGEP2), is there any other way to perpare for this change?<br>
<br>
The main one is to make sure you avoid using getElementType on<br>
pointers. If you're writing a front-end this probably means you need<br>
to keep your AST's representation of element types alongside LLVM<br>
pointer Values in your own data-structures (beware, llvm::Type may not<br>
be enough if that contains nested pointers). That lets you pass them<br>
into the instructions that will need it (loads, GEPs, allocas etc).<br>
<br>
> And also - is it possible to use something like opaque pointers (that is using a single pointer type) even before the switch has been flipped in LLVM?<br>
<br>
Not in current LLVM. I have a branch that has some work on them. I've<br>
been meaning to upload, document and propose a real path forwards on<br>
llvm-dev but other things have gotten in the way up to now. I think<br>
there's quite a bit of infrastructure work just to make the bitcode<br>
and IR layers accept opaque pointers, and after that many passes and<br>
other components assert when they first encounter an opaque pointer.<br></blockquote><div><br></div><div>Awesome :) (I think last I really looked at this my next hurdle was going to be intrinsics that are sort of name-mangled overloaded based on parameter types, but I can see how adding a new opaque pointer type as part of a migration makes sense (maybe that's what John McCall suggested after I was a fair way down the original migration path... maybe, I forget) to exist in parallel and move things over to)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've not managed to fix all of those yet so I'm still a bit unsure how<br>
things will work then, but I'd expect at least some correctness and<br>
performance regressions to begin with. I'm hoping that work can happen<br>
incrementally and during this phase I hope people would be able to<br>
experiment and make sure they're ready.<br>
<br>
Cheers.<br>
<br>
Tim.<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>