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

Matt Arsenault via llvm-dev
2020-05-23T17:22:11Z

> On May 5, 2020, at 14:14, Amara Emerson <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200523/cd6ca3a7/attachment-0001.html>