[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