<div dir="ltr">Yep, agreed on all counts - and would be happy to find some volunteers to help out with the typeless pointer work, but I do intend to get back around to it (probably need to do some inventorying myself so I can point others to the right places/direction/overall approach at the very least).<br><br>- Dave</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 3, 2016 at 6:51 AM Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 3 October 2016 at 06:46, Artur Pilipenko <<a href="mailto:apilipenko@azulsystems.com" class="gmail_msg" target="_blank">apilipenko@azulsystems.com</a>> wrote:<br class="gmail_msg">
> The only reason for intrinsic mangling is the way to get a unique symbolic<br class="gmail_msg">
> name. One we have typeless pointers I expect that pointer arguments are<br class="gmail_msg">
> mangled as ‘p’ and we won’t have any headache with remangling. But now we<br class="gmail_msg">
> still can have two overloaded intrinsics which only differ by pointer type:<br class="gmail_msg">
> declare @llvm.intrinsic(i8* p)<br class="gmail_msg">
> declare @llvm.intrinsic(i32* p)<br class="gmail_msg">
<br class="gmail_msg">
My thought was to allow overloading such that the above would be legal<br class="gmail_msg">
IR, but I can see the annoyance in supporting that. Given that the<br class="gmail_msg">
mangling becomes trivial once we have typeless pointers (and therefore<br class="gmail_msg">
non-cyclic types), I guess there is nothing do to about it for now.<br class="gmail_msg">
<br class="gmail_msg">
Thanks,<br class="gmail_msg">
Rafael<br class="gmail_msg">
</blockquote></div>