[PATCH/RFC] fold zext(setcc) into a larger setcc

[Matt Arsenault]

On 01/26/2015 04:35 PM, Fiona Glaser wrote:
> On an out-of-tree target, IR similar to the attached causes the 
> emission of the following instructions (pseudocode):
>
> setcc dst16, cc
> zext dst32, dst16
>
> The attached patch fixes it to be the expected:
>
> setcc dst32, cc
>
> because the out-of-tree target supports 32-bit setcc.

Does it also support 16-bit setcc result types or return different sized 
types for different compared types? I don't think this patch is 
generally correct. It isn't correct to blindly promote the setcc type, 
especially with any given promotion type. At the very least this would 
only be valid to combine zext if the target's boolean content is 
ZeroOrOneBooleanContent etc. setccs should only be created with a type 
from getSetCCResultType, and any random extended type you give it 
probably won't work

-Matt


>
> But when testing on x86, this crashes with the assertion “Assertion 
> failed: (((!Subtarget->hasAVX512() && VT == MVT::i8) || (VT == 
> MVT::i1)) && "SetCC type must be 8-bit or 1-bit integer”)”. If I 
> remove the !LegalTypes condition, it works fine, but this means that 
> canonicalizing to a non-legal type prior to type legalization is 
> somehow breaking x86.
>
> Does anyone have any idea what’s going on here, or if I’m just 
> approaching this entirely wrong?
>
> Fiona
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150126/487cbabe/attachment.html>