I have posted a new version of the patch at:
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684473.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
s
Hi!
On Thu, May 08, 2025 at 07:44:26PM -0400, Michael Meissner wrote:
> In bug PR target/118541 on power9, power10, and power11 systems, for the
> function:
>
> extern double __ieee754_acos (double);
>
> double
> __acospi (double x)
> {
> double ret =
Hi!
On Wed, May 21, 2025 at 06:27:38AM +0200, Richard Biener wrote:
> On Wed, May 21, 2025 at 12:30 AM Segher Boessenkool
> wrote:
> >
> > On Mon, May 12, 2025 at 06:35:15PM -0400, Michael Meissner wrote:
> > > On Mon, May 12, 2025 at 01:24:04PM +0530, Surya Kumari Jangala wrote:
> > > > Hi Mike,
On Wed, May 21, 2025 at 12:30 AM Segher Boessenkool
wrote:
>
> On Mon, May 12, 2025 at 06:35:15PM -0400, Michael Meissner wrote:
> > On Mon, May 12, 2025 at 01:24:04PM +0530, Surya Kumari Jangala wrote:
> > > Hi Mike,
> > > Irrespective of whether -Ofast is used or not, should’nt we generate
> >
On Mon, May 12, 2025 at 06:35:15PM -0400, Michael Meissner wrote:
> On Mon, May 12, 2025 at 01:24:04PM +0530, Surya Kumari Jangala wrote:
> > Hi Mike,
> > Irrespective of whether -Ofast is used or not, should’nt we generate
> > XSCMPUDP instruction for ‘isgreater()’ operation? This is because XSCM
On Mon, May 12, 2025 at 06:35:15PM -0400, Michael Meissner wrote:
> On Mon, May 12, 2025 at 01:24:04PM +0530, Surya Kumari Jangala wrote:
> > Hi Mike,
> > Irrespective of whether -Ofast is used or not, should’nt we generate
> > XSCMPUDP instruction for ‘isgreater()’ operation? This is because XSCM
On Mon, May 12, 2025 at 01:24:04PM +0530, Surya Kumari Jangala wrote:
> Hi Mike,
> Irrespective of whether -Ofast is used or not, should’nt we generate XSCMPUDP
> instruction for ‘isgreater()’ operation? This is because XSCMPGTDP insn will
> generate a trap if either operand is an SNaN or a QNaN.
Hi Mike,
Irrespective of whether -Ofast is used or not, should’nt we generate XSCMPUDP
instruction for ‘isgreater()’ operation? This is because XSCMPGTDP insn will
generate a trap if either operand is an SNaN or a QNaN. Whereas, XSCMPUDP insn
will generate a trap only if either operand is an SNa
This has been posted previously. This patch includes fixing some typos that
Bernhard Reutner-Fischer suggested.
In bug PR target/118541 on power9, power10, and power11 systems, for the
function:
extern double __ieee754_acos (double);
double
__acospi (double x)
{
On 2/7/25 11:48 PM, Michael Meissner wrote:
> On Fri, Feb 07, 2025 at 05:51:19PM -0600, Peter Bergner wrote:
>> On 2/7/25 4:02 PM, Michael Meissner wrote:
>>> (define_predicate "invert_fpmask_comparison_operator"
>>> - (match_code "ne,unlt,unle"))
>>> + (ior (match_code "ne")
>>> + (and (m
On Fri, Feb 07, 2025 at 05:51:19PM -0600, Peter Bergner wrote:
> On 2/7/25 4:02 PM, Michael Meissner wrote:
> > (define_predicate "invert_fpmask_comparison_operator"
> > - (match_code "ne,unlt,unle"))
> > + (ior (match_code "ne")
> > + (and (match_code "unlt,unle")
> > + (match_test
On Fri, Feb 07, 2025 at 05:51:19PM -0600, Peter Bergner wrote:
> On 2/7/25 4:02 PM, Michael Meissner wrote:
> > (define_predicate "invert_fpmask_comparison_operator"
> > - (match_code "ne,unlt,unle"))
> > + (ior (match_code "ne")
> > + (and (match_code "unlt,unle")
> > + (match_test
On 2/7/25 4:02 PM, Michael Meissner wrote:
> (define_predicate "invert_fpmask_comparison_operator"
> - (match_code "ne,unlt,unle"))
> + (ior (match_code "ne")
> + (and (match_code "unlt,unle")
> + (match_test "!HONOR_NANS (DFmode) || !TARGET_P9_VECTOR"
Is it always safe to use
This is version 2 of the patch.
Changes from the V1 patch:
1: I added a test in invert_fpmask_comparison_operator to not allow UNLE and
UNLT unless fast math is in force. Both invert_fpmask_comparison_operator and
fpmask_comparison_operator are used to form floating point conditional moves on
Po
On 31/01/25 8:24 am, Michael Meissner wrote:
> Fix PR 118541, do not generate unordered fp cmoves for IEEE compares.
>
> In bug PR target/118541 on power9, power10, and power11 systems, for the
> function:
>
> extern double __ieee754_acos (double);
&
On Fri, Jan 31, 2025 at 08:04:53AM +0100, Richard Biener wrote:
> I fail to see where -Ofast is allowed, but only see the pre-existing
> flag check above
> which checks for no NaN/Inf rather than sNaN - the latter would be checked
> with
> HONOR_SNANS (mode).
Well -Ofast sets the flag_finite_math
On Fri, Jan 31, 2025 at 08:04:53AM +0100, Richard Biener wrote:
> On Fri, Jan 31, 2025 at 3:55 AM Michael Meissner
> wrote:
> >
> > Fix PR 118541, do not generate unordered fp cmoves for IEEE compares.
> >
> > In bug PR target/118541 on power9, power10, and power11
On Fri, Jan 31, 2025 at 3:55 AM Michael Meissner wrote:
>
> Fix PR 118541, do not generate unordered fp cmoves for IEEE compares.
>
> In bug PR target/118541 on power9, power10, and power11 systems, for the
> function:
>
> extern double __ieee754_acos (double
Fix PR 118541, do not generate unordered fp cmoves for IEEE compares.
In bug PR target/118541 on power9, power10, and power11 systems, for the
function:
extern double __ieee754_acos (double);
double
__acospi (double x)
{
double ret = __ieee754_acos (x
19 matches
Mail list logo
