> On Jun 22, 2015, at 9:31 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > This part is scary. > > Having a third party library dependency is very undesirable from a testing perspective. > >I agree, but it’s what we are stuck with for now. It’s an optional dependency now, so most people building LLVM won’t need to worry about it> > One of the important property of MC is avoiding the need for two code paths in the code generator. > > If MC cannot support the format you need, we should work on fixing that in a way that maintains the property that most code is shared when writing objects or assembly. This is a need that is shared by Webassembly I think. > > My suggestion would be to start with just the assembly printing path and work to figure out what needs to happen in MC. > >It will take a long time to come up with a replacement for emitting BRIG in MC. How blocking of an issue is this to getting this committed? If really necessary, I can strip out the BRIG stuff, but would need to constantly maintain a patch re-adding it on top of trunk which would be a huge hassle so I would rather not. -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150630/1a7b830c/attachment.html>
> > One of the important property of MC is avoiding the need for two code > paths in the code generator. > > If MC cannot support the format you need, we should work on fixing that in > a way that maintains the property that most code is shared when writing > objects or assembly. This is a need that is shared by Webassembly I think. > > > My suggestion would be to start with just the assembly printing path and > work to figure out what needs to happen in MC. > > > It will take a long time to come up with a replacement for emitting BRIG > in MC. How blocking of an issue is this to getting this committed? If > really necessary, I can strip out the BRIG stuff, but would need to > constantly maintain a patch re-adding it on top of trunk which would be a > huge hassle so I would rather not. >Dan and I have talked to a few folks who have given us the same feedback for WebAssembly: we should consider using MC for virtual ISA emission, even though it isn't quite suitable as it exists in LLVM today. It's an opportunity to fix LLVM. Dan and I don't know much about MC, but we are going to explore this route. I have no opinion on how this should affect HSAIL's current patch. Dan and I are willing to take the lead on this, and would be happy to work with other virtual ISAs to make sure architectural changes to MC make sense for their usecases. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150630/bfe1c19b/attachment.html>
On Tue, Jun 30, 2015 at 5:13 PM, Matt Arsenault <arsenm2 at gmail.com> wrote:> > On Jun 22, 2015, at 9:31 AM, Rafael Espíndola <rafael.espindola at gmail.com> > wrote: > > This part is scary. > > Having a third party library dependency is very undesirable from a testing > perspective. > > > I agree, but it’s what we are stuck with for now. It’s an optional > dependency now, so most people building LLVM won’t need to worry about it > > > One of the important property of MC is avoiding the need for two code > paths in the code generator. > > If MC cannot support the format you need, we should work on fixing that in > a way that maintains the property that most code is shared when writing > objects or assembly. This is a need that is shared by Webassembly I think. > > > My suggestion would be to start with just the assembly printing path and > work to figure out what needs to happen in MC. > > > It will take a long time to come up with a replacement for emitting BRIG > in MC. How blocking of an issue is this to getting this committed? If > really necessary, I can strip out the BRIG stuff, but would need to > constantly maintain a patch re-adding it on top of trunk which would be a > huge hassle so I would rather not. >Could you maybe explain a bit more about BRIG and the barriers to using MC for it? -- Sean Silva> > -Matt > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150630/8a39df9c/attachment.html>
On Tue, Jun 30, 2015 at 7:34 PM, JF Bastien <jfb at google.com> wrote:> One of the important property of MC is avoiding the need for two code >> paths in the code generator. >> >> If MC cannot support the format you need, we should work on fixing that >> in a way that maintains the property that most code is shared when writing >> objects or assembly. This is a need that is shared by Webassembly I think. >> >> >> My suggestion would be to start with just the assembly printing path and >> work to figure out what needs to happen in MC. >> >> >> It will take a long time to come up with a replacement for emitting BRIG >> in MC. How blocking of an issue is this to getting this committed? If >> really necessary, I can strip out the BRIG stuff, but would need to >> constantly maintain a patch re-adding it on top of trunk which would be a >> huge hassle so I would rather not. >> > > Dan and I have talked to a few folks who have given us the same feedback > for WebAssembly: we should consider using MC for virtual ISA emission, even > though it isn't quite suitable as it exists in LLVM today. It's an > opportunity to fix LLVM. Dan and I don't know much about MC, but we are > going to explore this route. >It might be worth having a discussion on LLVMDev about "virtual ISA's". With HSAIL, WebAssembly, and SPIR-V off the top of my head, it sounds like we should have some sort of common discussion about them, since some of the issues appear to be the same. -- Sean Silva> > I have no opinion on how this should affect HSAIL's current patch. Dan and > I are willing to take the lead on this, and would be happy to work with > other virtual ISAs to make sure architectural changes to MC make sense for > their usecases. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150630/b0b722e1/attachment.html>
On 06/30/2015 07:57 PM, Sean Silva wrote:> Could you maybe explain a bit more about BRIG and the barriers to > using MC for it? >The main problem is it isn't streamable. Everything is split into multiple sections in the binary. For example, instructions have their operands placed in a different section and the instruction encoding includes the offset into the other section. libHSAIL needs to construct the full output for the module in memory and then emit code at the end, which is not how MC expects binary formats to work. This particular problem we've thought might be fixable with lots of custom fixups. There are also issues with debug info. One of the problems is that the text format currently doesn't have a way of representing DWARF, and BRIG has its own special handling of DWARF in a separate section as well. Binary formats and MC aren't areas I'm particularly familiar with. -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150701/0711f7ab/attachment.html>
> It will take a long time to come up with a replacement for emitting BRIG in > MC. How blocking of an issue is this to getting this committed? If really > necessary, I can strip out the BRIG stuff, but would need to constantly > maintain a patch re-adding it on top of trunk which would be a huge hassle > so I would rather not.If committed it is the LLVM community that takes the burden, so I don't think we should do it. Cheers, Rafael