On Sat, Feb 15, 2014 at 7:08 PM, Eric Christopher <echristo at gmail.com> wrote:> On Tue, Feb 11, 2014 at 9:46 AM, Tom Roeder <tmroeder at google.com> wrote: >> On Tue, Feb 11, 2014 at 9:12 AM, Reid Kleckner <rnk at google.com> wrote: >>> On Tue, Feb 11, 2014 at 12:28 AM, Richard Osborne <richard at xmos.com> wrote: >>>> >>>> >>>> On 11 Feb 2014, at 08:15, Eric Christopher <echristo at gmail.com> wrote: >>>> >>>> > On Mon, Feb 10, 2014 at 11:51 PM, Reid Kleckner <rnk at google.com> wrote: >>>> >> >>>> >> >>>> >> >>>> >> IIRC this came up before, and I don't think we expose anything like a >>>> >> jump >>>> >> table at the IR level. As an IR-to-IR transform, I think asm is the >>>> >> only >>>> >> way to do it. >>>> > >>>> > I'd have to look more at what he's doing, but wouldn't a simple switch >>>> > statement in IR suffice? Efficiency would be up to the various >>>> > lowering mechanisms, but it wouldn't require inline asm. >> >> I'm not sure I follow how this would work. Could you expand on this, please? >> > > I think you've already rebutted it below, so how about another idea? :) > > What about creating a pseudo-plt in the back end that will create this > jump table for you at object emission time? > > Throwing out ideas in an attempt to avoid passes creating inline > assembly - especially since we're looking at an IR level pass. >I'm definitely interested in removing the inline asm bits. I'm not sure what you mean by a pseudo-plt, though; do you mean hooking into the code that generates the Procedure Linkage Table? I really don't know much about the LLVM back end, so I'd have to learn how that all works in LLVM first.
On Mon, Feb 24, 2014 at 4:33 PM, Tom Roeder <tmroeder at google.com> wrote:> On Sat, Feb 15, 2014 at 7:08 PM, Eric Christopher <echristo at gmail.com> wrote: >> On Tue, Feb 11, 2014 at 9:46 AM, Tom Roeder <tmroeder at google.com> wrote: >>> On Tue, Feb 11, 2014 at 9:12 AM, Reid Kleckner <rnk at google.com> wrote: >>>> On Tue, Feb 11, 2014 at 12:28 AM, Richard Osborne <richard at xmos.com> wrote: >>>>> >>>>> >>>>> On 11 Feb 2014, at 08:15, Eric Christopher <echristo at gmail.com> wrote: >>>>> >>>>> > On Mon, Feb 10, 2014 at 11:51 PM, Reid Kleckner <rnk at google.com> wrote: >>>>> >> >>>>> >> >>>>> >> >>>>> >> IIRC this came up before, and I don't think we expose anything like a >>>>> >> jump >>>>> >> table at the IR level. As an IR-to-IR transform, I think asm is the >>>>> >> only >>>>> >> way to do it. >>>>> > >>>>> > I'd have to look more at what he's doing, but wouldn't a simple switch >>>>> > statement in IR suffice? Efficiency would be up to the various >>>>> > lowering mechanisms, but it wouldn't require inline asm. >>> >>> I'm not sure I follow how this would work. Could you expand on this, please? >>> >> >> I think you've already rebutted it below, so how about another idea? :) >> >> What about creating a pseudo-plt in the back end that will create this >> jump table for you at object emission time? >> >> Throwing out ideas in an attempt to avoid passes creating inline >> assembly - especially since we're looking at an IR level pass. >> > > I'm definitely interested in removing the inline asm bits. I'm not > sure what you mean by a pseudo-plt, though; do you mean hooking into > the code that generates the Procedure Linkage Table? I really don't > know much about the LLVM back end, so I'd have to learn how that all > works in LLVM first.Either that or using similar functionality. It's definitely more complicated on the start than using the inline assembly. -eric
On Tue, Feb 25, 2014 at 5:41 PM, Eric Christopher <echristo at gmail.com>wrote:> On Mon, Feb 24, 2014 at 4:33 PM, Tom Roeder <tmroeder at google.com> wrote: > > > > I'm definitely interested in removing the inline asm bits. I'm not > > sure what you mean by a pseudo-plt, though; do you mean hooking into > > the code that generates the Procedure Linkage Table? I really don't > > know much about the LLVM back end, so I'd have to learn how that all > > works in LLVM first. > > Either that or using similar functionality. It's definitely more > complicated on the start than using the inline assembly. > > -eric >I've been digging around in the back end for a bit now, trying to figure out the best way to implement the jump-instruction tables; there's already support for jump tables there, but it's a different kind of jump table than the one I want. One direction that looks promising to me is to add an intrinsic, something like: declare void @llvm.jump.instr.table.entry(i8*, i8*) The first argument would be the original function (the one that gets jumped to in the table), and the second argument is the _JT function declared but not defined by the pass. Then I can add a custom lowering in each supported architecture that would turn this into a labeled jump instruction something like .globl func_JT func_JT: jmp func at PLT The CFI pass would add a special function that would consist only of these intrinsics, one for each jump statement needed by the table, and padded to a power of two using another special intrinsic (something like llvm.undefined.instr) that would lower to an undefined instruction (like ud2 in x86). I'd appreciate feedback anyone might have about this proposal. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140317/efb5749f/attachment.html>