[PATCH] D124697: Distinguish between different forms of "address-taken" MachineBasicBlocks

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 23 18:05:03 PDT 2022


arsenm added inline comments.


================
Comment at: llvm/include/llvm/CodeGen/MachineBasicBlock.h:152
+  /// to an IR-level "blockaddress" constant.
+  bool IRBlockAddressTaken = false;
 
----------------
efriedma wrote:
> efriedma wrote:
> > arsenm wrote:
> > > efriedma wrote:
> > > > arsenm wrote:
> > > > > If you're going to depend on the underlying IR block, you don't really need another field inside MachineBasicBlock. You can just query directly from the IR
> > > > In general, there are multiple MachineBasicBlocks which correspond to a single IR BasicBlock; when we split a block for whatever reason, getBasicBlock() is the same for both halves.  We need to know which one is the jump destination.
> > > Does it actually make sense to preserve the IR block if the block is split? Is the IR block used for anything else? Maybe for block splitting the second half of the block shouldn't have the IR link
> > It might be possible to mess with the value stored as getBasicBlock(); as far as I can tell, the result is mostly used for debug prints and as an argument to CreateMachineBasicBlock().  It is used for a few other (possibly dubious) things: to get MD_loop/MD_make_implicit metadata, to get debug locations, to get the LandingPadInst for a landing pad.  Nothing we couldn't handle some other way, I think.
> > 
> > If we want to go in that direction, though, I might as well just replace `bool IRBlockAddressTaken` with `BasicBlock *IRBlockAddress`", and avoid the dependency on getBasicBlock() altogether.
> @arsenm Ping
Right, that's what I was suggesting. Just go through the IR block. I suspect the IR block is misleading in the split case anyway


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124697



More information about the llvm-commits mailing list