<div dir="ltr"><div>I'm curious about this code in ReduceLoadWidth (and in DAGCombiner in general):</div><div><br></div><div><span>if</span> (LegalOperations && !TLI.isLoadExtLegal(ExtType, ExtVT))<br><a name="l06166"></a><span>   return</span> <a href="http://llvm.org/docs/doxygen/html/classllvm_1_1SDValue.html"><font color="#0066cc">SDValue</font></a>();</div><div><br></div><div>LegalOperations is false for the first pre-legalize pass and true for the post-legalize pass. The first pass is target-independent yes? So that makes sense.</div><div><br></div><div>The issue we are having is this: we don't support 8 bit loads and we don't support 8 bit extloads, so we end up with LD1 with zext after either the first pass or the second pass (depending on the test case). If we add the TargetLowering callback method setLoadExtAction(ISD::ZEXTLOAD, MVT::i8, Expand) then it crashes during legalization and if we don't have that in then it crashes during instruction selection.</div><div><br></div><div>There are two ways to fix this: </div><div><br></div><div>1) Add the setLoadExtAction AND comment out 'LegalOperations &&' in the conditional. (this solves the problem)</div><div><br></div><div>2) Create a custom expand to undo the optimization added by ReduceLoadWidth. </div><div><br></div><div>The 2nd approach seems more in line with what LLVM infrastructure wants but it seems silly to have to undo an optimization? </div><div><br></div><div>Essentially, we have some bit packing structures and the code is trying to get the upper bits. The initial dag generates an LD2 with srl (which makes sense, it's what we want). The DAGCombiner then goes in and changes that LD2 with srl to an LD1 zextload, which we don't support.</div><div><br></div><div>Why is LegalOperations really needed here? What is the purpose and point of this? It seems you could eliminate this and be all the better for it.</div><div><br></div><div>Thanks.</div></div>