Hi Kito,
> I am convinced that is OK for now, I agree modeling fflags would be a
> rabbit hole, I tried to build a full GNU toolchain with my quick patch
> and saw many ICE during build libraries, that definitely should be a
> long-term optimization project.
>
> Although I'm thinking if we should
Hi Maciej:
I am convinced that is OK for now, I agree modeling fflags would be a
rabbit hole, I tried to build a full GNU toolchain with my quick patch
and saw many ICE during build libraries, that definitely should be a
long-term optimization project.
Although I'm thinking if we should default -
On Mon, 4 Jul 2022, Maciej W. Rozycki wrote:
> These instructions are only produced via an expander already, so change
> the expander to emit individual RTL insns for each machine instruction
> in the ultimate ultimate sequence produced rather than deferring to a
> single RTL insn producing the
We have unordered FP comparisons implemented as RTL insns that produce
multiple machine instructions. Such RTL insns are hard to match with a
processor pipeline description and additionally there is a redundant
SNEZ instruction produced on the result of these comparisons even though
the FLT.fm
