[llvm-dev] RFC: [GlobalISel] propagating int/float type information

[Daniel Sanders via llvm-dev]

> On 23 May 2020, at 10:22, Matt Arsenault via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 
> 
>> On May 5, 2020, at 14:14, Amara Emerson <aemerson at apple.com <mailto:aemerson at apple.com>> wrote:
>> 
>> I don’t think it was me who said that but it’s a good point.
>> 
>> I see no good reason not to re-use the existing IR instructions for computation on BFloat, given that we do so for other uncommon FP formats as well. Which I think in turn leaves us with little choice but to mirror the IR here (adding separate opcodes for this case just seems wrong).
> 
> I thought about this a bit and I think adding separate LLTs is probably the right approach. We were ignoring the existence of ppcf128 anyway, so bfloat16 doesn’t really introduce a new issue. However, I do want to deviate from the IR and SelectionDAG’s treatment of integer vs. FP operations to preserve the current property GlobalISel has where integer operations are allowed to freely operate directly on FP values. As long as I’m not required to insert bitcasts to/from integer LLTs just to operate on the bits of an FP value, I’m OK with it. We would only consider these different types in floating point contexts, and they would implicitly behave as the equivalent sized integers elsewhere. The current intermediate bitcasts needed in various FP legalization code are quite annoying, and they’ve always been an obstacle to some combines.
> 
> -Matt

I realize I'm very late to this thread but while adding an extra set of opcodes is more in keeping with the existing design I'm inclined to agree that things like bfloat make that look like the wrong direction. I also want to keep most things using scalars rather than ints/floats though so that they're specializations of scalar rather than completely independent types.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200629/49f653a1/attachment-0001.html>