uweigand added a comment. In D72906#1837905 <https://reviews.llvm.org/D72906#1837905>, @craig.topper wrote:
> In D72906#1826849 <https://reviews.llvm.org/D72906#1826849>, @uweigand wrote: > > > In D72906#1826122 <https://reviews.llvm.org/D72906#1826122>, @craig.topper > > wrote: > > > > > In D72906#1826061 <https://reviews.llvm.org/D72906#1826061>, @uweigand > > > wrote: > > > > > > > > The constrained fcmp intrinsics don't allow the TRUE/FALSE predicates. > > > > > > > > Hmm, maybe they should then? The only reason I didn't add them > > > > initially was that I wasn't sure they were useful for anything; if they > > > > are, it should be straightforward to add them back. > > > > > > > > > What would we lower it to on a target that doesn’t support it natively? > > > > > > Any supported compare (quiet or signaling as appropriate, just so we get > > the correct exceptions), and then ignore the result (and use true/false > > constant result instead)? > > > Sure. Is that something we want to force all targets to have to implement > just to handle this case for X86? Unless we can come up with a generic DAG > combine to pick a valid condition alternate so that the lowering code for > each target doesn't have to deal with it. Hmm, OK. Given that this X86-specific builtin code seems to be the only place in clang where FCMP_TRUE/FCMP_FALSE can ever get emitted anyway, I guess you might as well implement the workaround (use some other compare to get the exception) right there, just for X86. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72906/new/ https://reviews.llvm.org/D72906 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
