[PATCH/RFC] fold zext(setcc) into a larger setcc
Matthew.Arsenault at amd.com
Mon Jan 26 17:52:05 PST 2015
On 01/26/2015 05:39 PM, Fiona Glaser wrote:
>> The aext -> select_cc here is OK, but in your patch it will combine zext (setcc) -> setcc. On a target that uses ZeroOrNegativeOneBooleanContent, that would produce a wider type with 0 upper bits which is not the same as the all 1 bits the larger compare result would give. There are also a lot of pre-existing bugs that mishandle this now that still assume 0/1 setcc results.
>> I guess I don't understand why this wouldn't already be happening during legalization if getSetCCResultType gives i32. I would not expect two different result types for the same setcc to ever work.
> What should one do if there are multiple valid SetCC result types?
> I checked the code for the out-of-tree target, and it has i16 set to the default result type, but the target also supports i32. Is the problem that LLVM doesn’t support optimizing for the case of a target that can pick and choose its SetCC result type?
Yes, the current handling of setcc types isn't great. I sometimes run
into places that assume the setcc type is always the same for all
compared types, and this is a level of complexity beyond that. I suppose
to really fix this problem you would probably need to add an
isValidSetCCResultType to handle this.
More information about the llvm-commits