Eric Christopher via llvm-dev
2017-Oct-03 21:30 UTC
[llvm-dev] TargetMachine vs LLVMTargetMachine
On Tue, Oct 3, 2017 at 8:54 AM Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > On 10/02/2017 10:57 PM, Matthias Braun via llvm-dev wrote: > > The distinction between the LLVMTargetMachine and TargetMachine classes > has become somewhat muddy recently. So I created: > > https://reviews.llvm.org/D38482 > > to clean things up. During review it was noted that we may rather merge > the two instead which looks like this: > > https://reviews.llvm.org/D38489 > > We really should choose one of the two over the status quo. Some points > for the discussion: > > - I am not aware of any target that is actually implementing TargetMachine > only but not LLVMTargetMachine (I assume the C backend used to do it before > it was removed) > - Even when merging the two, I believe it is still possible to implement a > target without linking to lib/CodeGen by returning nullptr for the various > methods related to CodeGen. > > > If this is true, then it seems like we don't lose anything from doing this > (and the code gets cleaner). We don't currently have anything in tree that >This was my suggestion of yesterday.> motivates the current split. It does seem useful to retain the ability to > have a direct-from-the-IR backend (mostly for translation into another IR). > >I'm dubious of this need, but as long as it doesn't add any overhead to the resultant code I'm good. -eric> -Hal > > > - The split would give some notion of an internal CodeGen interface and an > external interface visible to frontend/middleend etc. > - The code gets simpler when merging the two and we have to > document/explain less. > > - Matthias > > > _______________________________________________ > LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/795cdc9d/attachment.html>
Hal Finkel via llvm-dev
2017-Oct-03 21:37 UTC
[llvm-dev] TargetMachine vs LLVMTargetMachine
On 10/03/2017 04:30 PM, Eric Christopher wrote:> > > On Tue, Oct 3, 2017 at 8:54 AM Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > On 10/02/2017 10:57 PM, Matthias Braun via llvm-dev wrote: >> The distinction between the LLVMTargetMachine and TargetMachine >> classes has become somewhat muddy recently. So I created: >> >> https://reviews.llvm.org/D38482 >> >> to clean things up. During review it was noted that we may rather >> merge the two instead which looks like this: >> >> https://reviews.llvm.org/D38489 >> >> We really should choose one of the two over the status quo. Some >> points for the discussion: >> >> - I am not aware of any target that is actually implementing >> TargetMachine only but not LLVMTargetMachine (I assume the C >> backend used to do it before it was removed) >> - Even when merging the two, I believe it is still possible to >> implement a target without linking to lib/CodeGen by returning >> nullptr for the various methods related to CodeGen. > > If this is true, then it seems like we don't lose anything from > doing this (and the code gets cleaner). We don't currently have > anything in tree that > > > This was my suggestion of yesterday. > > motivates the current split. It does seem useful to retain the > ability to have a direct-from-the-IR backend (mostly for > translation into another IR). > > > I'm dubious of this need, but as long as it doesn't add any overhead > to the resultant code I'm good.The other thing that I asked in the other review thread, which I'll repeat here, is: does GlobalISel further reduce the motivation for this? The primary reason, as I understand it, for needing this kind of "direct" translation is to avoid going through type legalization. This can be important for software targeting FPGAs, for example, because the hardware can deal with arbitrary bit widths. With GlobalISel, can you go into CodeGen effectively without any legalization and then go on from there (if one needed such a thing)? The other motivation used to be to avoid register allocation, thus keeping the infinite set of virtual registers, but we've already addressed that issue. -Hal> > -eric > > -Hal > > >> - The split would give some notion of an internal CodeGen >> interface and an external interface visible to frontend/middleend >> etc. >> - The code gets simpler when merging the two and we have to >> document/explain less. >> >> - Matthias >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/5a0d46b9/attachment-0001.html>
Eric Christopher via llvm-dev
2017-Oct-03 21:42 UTC
[llvm-dev] TargetMachine vs LLVMTargetMachine
On Tue, Oct 3, 2017 at 2:37 PM Hal Finkel <hfinkel at anl.gov> wrote:> > On 10/03/2017 04:30 PM, Eric Christopher wrote: > > > > On Tue, Oct 3, 2017 at 8:54 AM Hal Finkel via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> On 10/02/2017 10:57 PM, Matthias Braun via llvm-dev wrote: >> >> The distinction between the LLVMTargetMachine and TargetMachine classes >> has become somewhat muddy recently. So I created: >> >> https://reviews.llvm.org/D38482 >> >> to clean things up. During review it was noted that we may rather merge >> the two instead which looks like this: >> >> https://reviews.llvm.org/D38489 >> >> We really should choose one of the two over the status quo. Some points >> for the discussion: >> >> - I am not aware of any target that is actually implementing >> TargetMachine only but not LLVMTargetMachine (I assume the C backend used >> to do it before it was removed) >> - Even when merging the two, I believe it is still possible to implement >> a target without linking to lib/CodeGen by returning nullptr for the >> various methods related to CodeGen. >> >> >> If this is true, then it seems like we don't lose anything from doing >> this (and the code gets cleaner). We don't currently have anything in tree >> that >> > > This was my suggestion of yesterday. > > >> motivates the current split. It does seem useful to retain the ability to >> have a direct-from-the-IR backend (mostly for translation into another IR). >> >> > I'm dubious of this need, but as long as it doesn't add any overhead to > the resultant code I'm good. > > > The other thing that I asked in the other review thread, which I'll repeat > here, is: does GlobalISel further reduce the motivation for this? The > primary reason, as I understand it, for needing this kind of "direct" > translation is to avoid going through type legalization. This can be > important for software targeting FPGAs, for example, because the hardware > can deal with arbitrary bit widths. With GlobalISel, can you go into > CodeGen effectively without any legalization and then go on from there (if > one needed such a thing)? > >Not right now, no. That said I'm uncertain how much we particularly care about keeping two classes here when we can just change how initialization works to provide nullptr versions of the local bits rather than having a separate overhead class. -eric> -Hal > > > > -eric > > >> -Hal >> >> >> - The split would give some notion of an internal CodeGen interface and >> an external interface visible to frontend/middleend etc. >> - The code gets simpler when merging the two and we have to >> document/explain less. >> >> - Matthias >> >> >> _______________________________________________ >> LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> -- >> Hal Finkel >> Lead, Compiler Technology and Programming Languages >> Leadership Computing Facility >> Argonne National Laboratory >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171003/29689499/attachment.html>