Intrinsic mangling and typeless pointers

[David Blaikie via llvm-commits]

That's a transitionary step I hadn't considered - implementing typeless
pointers just as "another pointer type" in the interim.

Possible, but the complication of supporting this new pointer type in the
rest of the IR might make it impractical - not sure. I'll certainly keep it
in mind.

On Mon, Oct 3, 2016 at 7:53 AM Philip Reames <listmail at philipreames.com>
wrote:

> One possibility here would be to add the syntax for typeless pointers and
> use them for intrinsics without using them globally yet.  Not sure how
> practical that is, but if it could be made to work it would be both a nice
> cleanup of a bunch of intrinsic code and a nice proof of concept for the
> typeless pointer work.  This would require that we allow a bitcast to/from
> the typeless pointer type.
>
> Philip
>
> On 10/03/2016 07:38 AM, David Blaikie via llvm-commits wrote:
>
> 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).
>
> - Dave
>
> On Mon, Oct 3, 2016 at 6:51 AM Rafael Espíndola <
> rafael.espindola at gmail.com> wrote:
>
> On 3 October 2016 at 06:46, Artur Pilipenko <apilipenko at azulsystems.com>
> wrote:
> > The only reason for intrinsic mangling is the way to get a unique
> symbolic
> > name. One we have typeless pointers I expect that pointer arguments are
> > mangled as ‘p’ and we won’t have any headache with remangling. But now we
> > still can have two overloaded intrinsics which only differ by pointer
> type:
> > declare @llvm.intrinsic(i8* p)
> > declare @llvm.intrinsic(i32* p)
>
> My thought was to allow overloading such that the above would be legal
> IR, but I can see the annoyance in supporting that. Given that the
> mangling becomes trivial once we have typeless pointers (and therefore
> non-cyclic types), I guess there is nothing do to about it for now.
>
> Thanks,
> Rafael
>
>
>
> _______________________________________________
> llvm-commits mailing listllvm-commits at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161003/f566490b/attachment.html>