This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 1/8] Document signaling for min, max and ltgt operations
On Wed, Aug 21, 2019 at 02:00:10PM +0200, Ilya Leoshkevich wrote:
> > Am 20.08.2019 um 19:13 schrieb Segher Boessenkool <segher@kernel.crashing.org>:
> > On Tue, Aug 20, 2019 at 06:13:00PM +0200, Ilya Leoshkevich wrote:
> >>> Am 20.08.2019 um 17:50 schrieb Segher Boessenkool <segher@kernel.crashing.org>:
> >>> There is currently no way to say (in trees or gimple or rtl) whether
> >>> comparisons are signaling ("ordered", generate a trap on an unordered
> >>> result). I am working on this, but :-)
> >>
> >> Isn't there? This whole series is based on the following assumption:
> >> LT, LE, GT, GE are definitely signaling; LTGT is most likely signaling
> >> as well; the rest are not signaling. This is based on gccint 11.6.3:
> >> Unary and Binary Expressions.
> >
> > There is currently no way to implement, say, iseqsig. And whether an
> > operation is signaling should be determined by the language frontend,
> > not separately by each backend!
>
> Wouldn't expressing it as ((x <= y) && (x >= y)) work?
That is optimised only partially (on gimple) (first a compare for <=,
then a branch if false, then return "==").
I meant it cannot be implemented directly as one RTL (or gimple) insn,
although it can be done as one machine insn on many architectures.
> > (There should be a signaling and a non-signaling version of every float
> > comparison that can be unordered).
>
> I wholeheartedly agree. I had to write quite a few ugly patterns to
> work around the lack of e.g. non-signaling GT.
Ooh, buy in, I like it. Thanks for the encouragement :-)
Segher