<div dir="ltr"><div>Ahmed,</div><div><br></div><div> Yes, we do not have an 8 bit type and do not support 8 bit loads/extloads. </div><div><br></div><div>  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 in. :)</div><div><br></div><div> 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 it). </div><div><br></div><div> 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.</div><div><br></div><div> I would just like to know the cleanest possible solution to this issue within LLVM infrastructure, assuming it's possible with the current 'core' code?</div><div><br></div><div>Thanks.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 4, 2015 at 2:20 PM, Ahmed Bougacha <span dir="ltr"><<a href="mailto:ahmed.bougacha@gmail.com" target="_blank">ahmed.bougacha@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wed, Mar 4, 2015 at 10:49 AM, Ahmed Bougacha<br>
<<a href="mailto:ahmed.bougacha@gmail.com">ahmed.bougacha@gmail.com</a>> wrote:<br>
> On Wed, Mar 4, 2015 at 10:26 AM, Ryan Taylor <<a href="mailto:ryta1203@gmail.com">ryta1203@gmail.com</a>> wrote:<br>
</span><span>>>  Yes, it is breaking during the legalize phase, depending on which<br>
>> TargetLowering callback method we use. For example, Custom will let it<br>
>> through to instructions selection, which it breaks at the that phase,<br>
>> otherwise I believe it breaks during legalization. If we use Expand instead,<br>
>> the assert during Legalize is: "EXTLOAD should always be supported". I don't<br>
>> really understand that message :)<br>
><br>
> Keep in mind "EXTLOAD" usually means "load, possibly followed by an<br>
> extension".  So, the "EXT" part is probably irrelevant here, if that's<br>
> what's bugging you ;)<br>
<br>
</span>Nevermind, grepping around shows this is specifically about<br>
ISD::EXTLOAD, in LegalizeLoadOps (LegalizeDAG.cpp).<br>
<br>
There's some code above, with an "isTypeLegal(SrcVT)" check, that<br>
tries to turn an EXTLOAD into LOAD+[SZ]EXT.  I'm guessing that on your<br>
target, both the EXTLOAD from i8 and the i8 type are illegal?<br>
<br>
In that case, again, I don't know how one could legalize this.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Ahmed<br>
</font></span></blockquote></div><br></div>