[LLVMdev] ReduceLoadWidth, DAGCombiner and non 8bit loads/extloads question.

[Ryan Taylor]

I'm curious about this code in ReduceLoadWidth (and in DAGCombiner in
general):

if (LegalOperations && !TLI.isLoadExtLegal(ExtType, ExtVT))
   return SDValue
<http://llvm.org/docs/doxygen/html/classllvm_1_1SDValue.html>();

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.

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.

There are two ways to fix this:

1) Add the setLoadExtAction AND comment out 'LegalOperations &&' in the
conditional. (this solves the problem)

2) Create a custom expand to undo the optimization added by
ReduceLoadWidth.

The 2nd approach seems more in line with what LLVM infrastructure wants but
it seems silly to have to undo an optimization?

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.

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.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150303/48eea60b/attachment.html>