ebevhan added inline comments.

================
Comment at: lib/CodeGen/SelectionDAG/LegalizeDAG.cpp:1119
+  case ISD::SSAT:
+    // Target legalization checked here?
+    Action = TargetLowering::Expand;
----------------
leonardchan wrote:
> ebevhan wrote:
> > leonardchan wrote:
> > > ebevhan wrote:
> > > > leonardchan wrote:
> > > > > @ebevhan Do you know if this is where checking if this intrinsic is 
> > > > > supported by the target should be? 
> > > > Yes, this would be it. For nodes like ssat and fixed-point ops, you 
> > > > could ask a custom target hook, maybe 
> > > > `TLI.getScaledOperationAction(<opcode>, <type>, <scale/sat_bw>)` to 
> > > > determine the legality of a given node.
> > > > 
> > > > When type-legalizing you also need to handle things for specific nodes 
> > > > as well, since things behave differently when you legalize 
> > > > operands/results on different nodes.
> > > > 
> > > > (Of course, this all depends on whether we do the legalization here or 
> > > > in IR instead.)
> > > Made the default action `Expand` for this in `TargetLoweringBase` and 
> > > targets can override this themselves.
> > > 
> > > I think ssat may not need a custom hook since I don't think it requires 
> > > anything extra like fixsmul if it has to be expanded. But I see what you 
> > > mean now by how different nodes may require different steps for 
> > > legalization.
> > You don't need an extra hook to determine anything extra for expansion, but 
> > you do need the hook to determine if it's legal in the first place. As I 
> > mentioned in another comment, an i16 ssat with a saturating width of 8 
> > might be legal, but an i16 ssat with saturating width 12 might not. The 
> > former must not be expanded, but the latter must.
> Got it. Just to clarify though, legalizations regarding the scale would only 
> apply for our mul/div intrinsics right? Operations like saturation and sat 
> add/sub which don't care about the scale do not need this hook right, since 
> it would also be useful for these operations to work on regular integers?
Saturating add/sub won't need anything, but I still think saturation requires 
some extra check to determine if an operation with a specific saturating 
bitwidth should be legal or expanded. As I mentioned, a saturation with a type 
might be legal for one saturating bitwidth but not for another.


Repository:
  rL LLVM

https://reviews.llvm.org/D52286



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to