[PATCH] D57243: GlobalISel: Allow bitcount ops to have different result type

Roman Tereshin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 5 11:50:07 PST 2019


rtereshin added a comment.

In D57243#1385704 <https://reviews.llvm.org/D57243#1385704>, @arsenm wrote:

> The type used in this case for the result has more to do with the type required for the operations after required for the legalization. The G_SUB can be done in either width, but the narrower sub seems like a more preferable canonical form.


That's a very good point. On the other hand, I think it's a general and expected behavior of the Legalizer to use truncates and extends to bridge the types. So it's possible to keep the result of the bit op itself as it is, truncate it if it's safe (due to the original narrow type of the source), and do the G_SUB of the truncated type.

Subsequent steps of the legalization, if they narrow the destination of the bit op itself, will eliminate that truncate as a legalization artifact. In the same time, having G_SUB with of a narrow type generated in the process of widening something isn't much of a problem contract-wise or introducing-loops-wise because AFAIK the legalizer in general legalizes one instruction at a time based on the properties on that instruction only, so that G_SUB will be legalized later on just like any other G_SUB with no interference from the surrounding ops. That latter argument is not true when it's different operands (or type indices) of the same opcode specifically because of what we're discussing here.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57243/new/

https://reviews.llvm.org/D57243





More information about the llvm-commits mailing list