This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 <>:
> > On Tue, Aug 20, 2019 at 06:13:00PM +0200, Ilya Leoshkevich wrote:
> >>> Am 20.08.2019 um 17:50 schrieb Segher Boessenkool <>:
> >>> 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 :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]