[PATCH] D140569: [AVR] Custom lower 32-bit shift instructions

Ayke via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 26 08:45:30 PST 2022


aykevl added inline comments.


================
Comment at: llvm/lib/Target/AVR/AVRISelLowering.cpp:291
+      // 32-bit shifts are converted to a loop in IR.
+      llvm_unreachable("Expected a constant shift!");
+    }
----------------
arsenm wrote:
> aykevl wrote:
> > benshi001 wrote:
> > > arsenm wrote:
> > > > aykevl wrote:
> > > > > benshi001 wrote:
> > > > > > `"Expected a constant shift amount!"`
> > > > > Fixed locally.
> > > > You can't guarantee this condition. If you don't want to handle this properly, should use emitError, or at least report_fatal_error and not unreachable. This could easily be run into by users
> > > Yes. This is problemetic. I guess the Ayke's intention is to let non-const shift amounts fall into the default ordinary process.
> > > You can't guarantee this condition. If you don't want to handle this properly, should use emitError, or at least report_fatal_error and not unreachable. This could easily be run into by users
> > 
> > How so? Non-constant shifts are expanded by an IR pass to constant shifts (in a loop), see llvm/lib/Target/AVR/AVRShiftExpand.cpp. Maybe there's a way to circumvent it but with some testing I couldn't come up with IR that hits this assert. But I'll change it to `report_fatal_error` in an update.
> > 
> > (I also have a local patch that removes the IR pass and instead handles non-constant shifts here).
> There's no verifier for this, so you still need to be more diligent about error handling. A DAG combine could still choose to introduce a non-constant shift amount, or any IR pass after the point you lowered it
Okay.
It's a `report_fatal_error` now so it won't silently miscompile here anymore. If it ever happens, it must be very rare because before this patch it would have resulted in a linker error (`__lshlsi3` etc) instead of a compiler error.


================
Comment at: llvm/lib/Target/AVR/AVRISelLowering.cpp:318
+    SDValue Result = DAG.getNode(Opc, dl, ResTys, SrcLo, SrcHi, Cnt);
+    return DAG.getNode(ISD::BUILD_PAIR, dl, MVT::i32, Result.getValue(0),
+                       Result.getValue(1));
----------------
arsenm wrote:
> aykevl wrote:
> > arsenm wrote:
> > > Why can't you handle everything here as a normal custom lowering? Why do you need the custom inserter?
> > I'm not sure what you mean? How can this be done in a different way?
> > 
> > If you mean building the entire thing in SelectionDAG, I think that would be a lot more complicated if not impossible because eventually I want to generate loops. I intend to introduce a later patch that lowers these shits to a loop if emitting the full sequence results in more instructions and `minsize` is set (avr-gcc does the same).
> If you need to emit control flow, you don't have much choice besides the custom inserter
Ok, understood. Next time I do an optimization that doesn't require flow control I'll try doing this in `XXXDAGToDAGISel::trySelect` (I assume that's what you mean?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140569



More information about the llvm-commits mailing list