+the people I hashed this out with so many months ago
I think it's a reasonable proposal, but obviously I floated it. :) Let's
try to get a second opinion.
Again, it's a syntax something like:
define void @foo() prefix [i8* x 2] { i8* @a, i8* @b } prologue [i8 x 4]
c"\xde\xad\xbe\xef" { ret void }
On Thu, Aug 21, 2014 at 1:58 PM, Ben Gamari <bgamari.foss at gmail.com>
wrote:
> Ben Gamari <bgamari.foss at gmail.com> writes:
>
> > Rafael Espíndola <rafael.espindola at gmail.com> writes:
> >
> >>> I suspected this was the case. Is a rework of prefix support
likely to
> >>> make it in for 3.5?
> >>>
> >>
> >> Unlikely. It has branched already and I don't know of anyone
working on
> it.
> >>
> > Fair enough. If there is consensus around a reasonably concrete
proposal
> > I would be happy to put together a patch (acknowledging that it
probably
> > won't make it in for 3.5). Does Reid's proposal seem
reasonable?
> >
> Ping?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140916/257cda4f/attachment.html>
Reid Kleckner <rnk at google.com> writes:> +the people I hashed this out with so many months ago > > I think it's a reasonable proposal, but obviously I floated it. :) Let's > try to get a second opinion. > > Again, it's a syntax something like: > define void @foo() prefix [i8* x 2] { i8* @a, i8* @b } prologue [i8 x 4] > c"\xde\xad\xbe\xef" { ret void } >As I've said previously, this syntax looks great to me. I haven't yet written any code against this interface but I see no reason why we wouldn't be able to use this to implement tables-next-to-code. Gabor's suggestion of prefix data on basic blocks is interesting but I'm not sure how this would be realized syntactically. Either way, would it be possible to see something like this in LLVM 3.6. For a variety of reasons the TNTC hack GHC's LLVM backend currently uses is becoming rather burdensome. It would be great to have a more principled approach soon. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141103/24f608e7/attachment.sig>
Ben Gamari <bgamari.foss at gmail.com> writes:> Reid Kleckner <rnk at google.com> writes: > >> +the people I hashed this out with so many months ago >> >> I think it's a reasonable proposal, but obviously I floated it. :) Let's >> try to get a second opinion. >> >> Again, it's a syntax something like: >> define void @foo() prefix [i8* x 2] { i8* @a, i8* @b } prologue [i8 x 4] >> c"\xde\xad\xbe\xef" { ret void } >> > As I've said previously, this syntax looks great to me. I haven't yet > written any code against this interface but I see no reason why we > wouldn't be able to use this to implement tables-next-to-code. > > Gabor's suggestion of prefix data on basic blocks is interesting but I'm > not sure how this would be realized syntactically. > > Either way, would it be possible to see something like this in LLVM > 3.6. For a variety of reasons the TNTC hack GHC's LLVM backend currently > uses is becoming rather burdensome. It would be great to have a more > principled approach soon. >Do any of your have any thoughts on this? I would be willing to put implementing this on my queue but I'd first want to know that this proposal sounds somewhat acceptable. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141114/4443b453/attachment.sig>