[PATCH] D80249: CodeGen: Don't lazily construct MachineFunctionInfo

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 16 08:53:35 PDT 2020


arsenm added a comment.

In D80249#2137666 <https://reviews.llvm.org/D80249#2137666>, @aemerson wrote:

> In D80249#2109204 <https://reviews.llvm.org/D80249#2109204>, @arsenm wrote:
>
> > In D80249#2107516 <https://reviews.llvm.org/D80249#2107516>, @kparzysz wrote:
> >
> > > A "create" function shouldn't return a null pointer.  I think there should be a default MFI that has nothing in it, and it would be what the `createMachineFunctionInfo` returns a pointer to in the absence of overrides.  It could even be statically allocated since is has no members:
> > >
> > >   virtual MachineFunctionInfo *
> > >   createMachineFunctionInfo(BumpPtrAllocator &Allocator, const Function &F,
> > >                             const TargetSubtargetInfo *STI) const {
> > >     static MachineFunctionInfo default;
> > >     return &default;
> > >   }
> > >
> > >
> > > Edit: fix indentation in the code
> >
> >
> > Alternatively, make it pure virtual or make it llvm_unreachable?
>
>
> This is ok with me.


As I mentioned in a previous comment, I think this ended up not working well. The dummy implementation I believe introduces build layer violations, and the pure virtual added more boilerplate to a couple of targets. Since this is only ever accessed from target code, I don't think there's much danger in using null here


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80249/new/

https://reviews.llvm.org/D80249





More information about the llvm-commits mailing list