[llvm-dev] [RFC] Eliminating non-IR floating-point controls in the selection DAG

[Serge Pavlov via llvm-dev]

Thanks,
--Serge


On Fri, Oct 29, 2021 at 7:23 AM Kaylor, Andrew <andrew.kaylor at intel.com>
wrote:

> That brings me to the RFC part of my message. I’d like to start updating
> the backend so that it doesn’t do things like this. As a general principle,
> I would say, “All semantics must be represented in the IR and the backend
> must respect the IR semantics.” And a corollary: “Anything which can be
> represented at the instruction level must be represented at the instruction
> level.” This corollary would eliminate potential conflicts between function
> attributes (like "unsafe-fp-math") and individual IR instructions.
>

>From the viewpoint of optimization, it is important to allow internal
representation in which different instructions may have different
properties including fast-math flags. The proposed general principle looks
very attractive, as it leads to flexible representation, which is also can
be safer as properties are queried from instruction only and not a
combination instruction+function+module.

It is not mandatory to keep flags in the instruction, maybe an instruction
method that returns a set of flags would be sufficient. Such a method would
calculate the flags if they are not kept in instruction. It could help
solving problems like https://llvm.org/PR52259, as having fast-math flags
on instructions like phi or select (and probably some others) does not look
natural.

Thanks,
--Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211102/67cb8cbf/attachment.html>