This resolves the issue of tablegen-erated includes in the headers for non-GlobalISel builds in a simpler way than before.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
What do you think of moving the class declaration to the .cpp file ? I don't think we need to export anything more than a "createAArch64InstructionSelector" function in AArch64.h; it was a mistake for me to put the class in the header in the first place.
That would get rid of the ifdef problem.
That sounds good to me. Can we tack it onto the end of the main patch series though? Some of those patches change <Target>InstructionSelector and I'd like to avoid resolving the conflicts if I don't need to.
That sounds good to me. Can we tack it onto the end of the main patch series though? Some of those patches change <Target>InstructionSelector and I'd like to avoid resolving the conflicts if I don't need to.
Sounds sensible to me.
@ab , what do you think?
Merge pain is temporary, but commit history is forever (I spend a lot of time resolving conflicts, but I spend way more git-blaming ancient commits). So, I'd favor doing the right thing in the first place if it's not too painful (maybe try it and abandon if it takes more than a few minutes to resolve? I suspect you'll have few problems as the header isn't affected by most changes)
Rewrote to move the class declaration into the .cpp.
The merge conflicts weren't too bad in the end. Git didn't attempt the merge at all but only a couple patches mattered.
lib/Target/AArch64/AArch64InstructionSelector.cpp | ||
---|---|---|
41 ↗ | (On Diff #93476) | These don't need to be in the llvm namespace anymore, btw. |