[LLVMdev] ReduceLoadWidth, DAGCombiner and non 8bit loads/extloads question.
ryta1203 at gmail.com
Wed Mar 4 11:43:01 PST 2015
Yes, we do not have an 8 bit type and do not support 8 bit loads/extloads.
For your first post, I imagine that anything that the DAGCombiner does it
could undo EXCEPT deciding to opt to a type that is not allowed, but that's
the design choice made by LLVM: to allow illegal operations AND types
during the pre-legalize phase, yes? So this is either a bug (design flaw)
or maybe someone more knowledgeable about a way to get around this without
having to change core code that cannot be put into off. release will chime
Yes, via Expand the assert is issued during LegalizeLoadOps (since it's
trying to legalize the 8 bit extload because the hardware does not support
The EXT part is not bugging me, I suppose it's possible that the
DAGCombiner could optimize to just an 8-bit load, but we've only seen this
opt if it's going to an extload, this is why I keep mentioning it. 8 bit
loads (NON_EXTLOAD) is also illegal on our machine. We do not support any
type of load that is 8 bit. Does LLVM also feel that 8 bit NON_EXTLOAD
should always be supported also? For example, the Legalize can expand an
EXTLOAD to NON_EXTLOAD and EXT but that would not help either, since we
don't support 8 bit loads.
I would just like to know the cleanest possible solution to this issue
within LLVM infrastructure, assuming it's possible with the current 'core'
On Wed, Mar 4, 2015 at 2:20 PM, Ahmed Bougacha <ahmed.bougacha at gmail.com>
> On Wed, Mar 4, 2015 at 10:49 AM, Ahmed Bougacha
> <ahmed.bougacha at gmail.com> wrote:
> > On Wed, Mar 4, 2015 at 10:26 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:
> >> 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
> >> the assert during Legalize is: "EXTLOAD should always be supported". I
> >> 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 ;)
> Nevermind, grepping around shows this is specifically about
> ISD::EXTLOAD, in LegalizeLoadOps (LegalizeDAG.cpp).
> There's some code above, with an "isTypeLegal(SrcVT)" check, that
> tries to turn an EXTLOAD into LOAD+[SZ]EXT. I'm guessing that on your
> target, both the EXTLOAD from i8 and the i8 type are illegal?
> In that case, again, I don't know how one could legalize this.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev