[PATCH/RFC] fold zext(setcc) into a larger setcc
Matthew.Arsenault at amd.com
Mon Jan 26 16:51:37 PST 2015
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
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits