paperchalice wrote:
> > > > > * CodeGen part needs `nsz` to fold pattern (uitofp (fptoui x)).
> > > >
> > > >
> > > > Does it? There's no integer value that would result in a signed zero
> > > > being the results of uitofp (or sitofp), so I would expect nsz to not
> > > > add any extra information.
> > >
> > >
> > > DAGCombiner tries to fold this pattern to trunc, which may not preserves
> > > the sign of zero, e.g. when x is -0.5.
> >
> >
> > Ah, looking at foldFPToIntToFP the transform currently depends on the
> > function-level no-signed-zeros-fp-math attribute, and this would allow the
> > instruction to be checked instead. It would be good to have this explained
> > in the PR (and commit) description.
>
> I still don't get it. Surely if you want to fold `(uitofp (fptoui x)) -->
> (trunc x)` then it's the `fptoui` that needs to have the `nsz` flag, to say
> that the input can be assumed not -0.0? What would `uitofp nsz` mean??
Agreed attaching `nsz` to `fptoui` would be better, but `nsz` flag in single
instruction might not make sense...
- For single `fptoui nsz`, the result is independent on the sign of the zero.
- For single `uitofp nsz`, the integer type doesn't have the concept "sign of
zero".
So `contract + nsz` would be better?
I would like to add fast-math support to `fpto{u,s}i`, IIRC PowerPC needs `afn`
semantic when lowering these instructions, but these instructions are not
floating-point valued.
https://github.com/llvm/llvm-project/pull/198470
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
