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

Ahmed Bougacha ahmed.bougacha at gmail.com
Wed Mar 4 10:49:22 PST 2015

On Wed, Mar 4, 2015 at 10:26 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:
> Ahmed,
>  Yes, this is the case, I'm sure many other 'spots' in DAGCombiner use this
> same check or use a similar check with LegalOperations. It just seems like
> bad form to have core code that generates an illegal node that legalization
> cannot seem to handle, unless I'm missing something, which is entirely
> possible. Potentially we are using the wrong LegalAction, though each I've
> tried breaks at different points so I don't think that's it.
>  Yes, it is breaking during the legalize phase, depending on which
> TargetLowering callback method we use. For example, Custom will let it
> through to instructions selection, which it breaks at the that phase,
> otherwise I believe it breaks during legalization. If we use Expand instead,
> the assert during Legalize is: "EXTLOAD should always be supported". I don't
> really understand that message :)

Keep in mind "EXTLOAD" usually means "load, possibly followed by an
extension".  So, the "EXT" part is probably irrelevant here, if that's
what's bugging you ;)

>  The pre-legalization canonicalization makes sense to me but either 1)
> legalize should be able to handle everything or 2) nodes that aren't going
> to be legal anyways should not be produced (though this obviously
> contradicts the term pre-legalize).
>   The SelectionDAGBuilder does not generate 8 bit loads nor 8 bit exloads.
>  There are other places we could fix this issue, accepting 8 bit extloads
> and then expanding it back further down the pipe, but this does seem a bit
> hacky.

Is there even a general way to do this?  Say a 2-byte load, from an
address right before a page boundary, (or the end of your address
space, if pages don't make sense on your target), was transformed into
a 1-byte load, from the last address.  You can't just turn it into a
2-byte load, you need to also adjust the pointer.  If you want to just
legalize a 1-byte loads into 2-byte, you need to know whether to do it
"up" or "down", no?  If you just have a 1-byte load with no
information on the address, you can't do that?  Or am I missing

For a concrete example, consider:

    (and (load i16* %p), 0xFF00)

turning into:

    (load i8* (%p + 1))

How do you legalize that?  The obvious thing would be:

    (and (load i16* (%p + 1)), 0xFF)

But if %p is dynamically (~(uintptr_t)0), that's a bad idea.

So, in some cases you'd need to turn it back into

    (and (load i16* ((%p + 1) - 1)), 0xFF00)

But by the time you're legalizing, you lost the "some cases" information.

That's what the assert is saying, and the core problem with the
legalization, no?  What does it even mean to legalize a 1-byte load?


More information about the llvm-dev mailing list