I think we can model the signed zero problem by keeping track of a
sign property, similar to how we keep track of a NAN property. The
property can be yes, no, or unknown, and would apply to the entire
range.
[0.0, 0.0] SIGN => -0.0 singleton
[0.0, 0.0] !SIGN=> +0.0 singleton
[0.0, 0.0]
On 8/29/22 19:07, Jeff Law via Gcc-patches wrote:
One of the more interesting ones is to try to limit the range of the
input to the trigonometric functions - that way you could use ones
without any argument reduction phase ...
The difficult part is that most of the trig stuff is in
> On Aug 29, 2022, at 1:07 PM, Jeff Law via Gcc-patches
> wrote:
>
> ...
> I guess we could do specialization based on the input range. So rather than
> calling "sin" we could call a special one that didn't have the reduction step
> when we know the input value is in a sensible range.
On 8/29/2022 9:13 AM, Toon Moene wrote:
On 8/29/22 17:08, Jeff Law via Gcc-patches wrote:
However, I'm hoping to forget as many floating point details, as fast
as possible, as soon as I can ;-).
Actually FP isn't that bad -- I'd largely avoided it for decades, but
didn't have a choice
On Mon, Aug 29, 2022 at 5:08 PM Jeff Law wrote:
>
>
>
> On 8/29/2022 8:26 AM, Aldy Hernandez wrote:
> > On Mon, Aug 29, 2022 at 4:22 PM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >> On 8/29/2022 7:31 AM, Aldy Hernandez via Gcc-patches wrote:
> >>> On Mon, Aug 29, 2022 at 3:22 PM Jakub
On 8/29/22 17:08, Jeff Law via Gcc-patches wrote:
However, I'm hoping to forget as many floating point details, as fast
as possible, as soon as I can ;-).
Actually FP isn't that bad -- I'd largely avoided it for decades, but
didn't have a choice earlier this year. And there's a lot more
On 8/29/2022 8:26 AM, Aldy Hernandez wrote:
On Mon, Aug 29, 2022 at 4:22 PM Jeff Law via Gcc-patches
wrote:
On 8/29/2022 7:31 AM, Aldy Hernandez via Gcc-patches wrote:
On Mon, Aug 29, 2022 at 3:22 PM Jakub Jelinek wrote:
On Mon, Aug 29, 2022 at 03:13:21PM +0200, Aldy Hernandez wrote:
On Mon, Aug 29, 2022 at 4:22 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 8/29/2022 7:31 AM, Aldy Hernandez via Gcc-patches wrote:
> > On Mon, Aug 29, 2022 at 3:22 PM Jakub Jelinek wrote:
> >> On Mon, Aug 29, 2022 at 03:13:21PM +0200, Aldy Hernandez wrote:
> >>> It seems to me we can do this
On 8/29/2022 7:31 AM, Aldy Hernandez via Gcc-patches wrote:
On Mon, Aug 29, 2022 at 3:22 PM Jakub Jelinek wrote:
On Mon, Aug 29, 2022 at 03:13:21PM +0200, Aldy Hernandez wrote:
It seems to me we can do this optimization regardless, but then treat
positive and negative zero the same
On Mon, Aug 29, 2022 at 3:22 PM Jakub Jelinek wrote:
>
> On Mon, Aug 29, 2022 at 03:13:21PM +0200, Aldy Hernandez wrote:
> > It seems to me we can do this optimization regardless, but then treat
> > positive and negative zero the same throughout the frange class.
> > Particularly, in
On Mon, Aug 29, 2022 at 03:13:21PM +0200, Aldy Hernandez wrote:
> It seems to me we can do this optimization regardless, but then treat
> positive and negative zero the same throughout the frange class.
> Particularly, in frange::singleton_p(). We should never return TRUE
> for any version of
On Fri, Aug 26, 2022 at 6:40 PM Jakub Jelinek wrote:
>
> On Fri, Aug 26, 2022 at 05:46:06PM +0200, Aldy Hernandez wrote:
> > On the true side of x == -0.0, we can't just blindly value propagate
> > the -0.0 into every use of x because x could be +0.0 (or vice versa).
> >
> > With this change, we
On Fri, Aug 26, 2022 at 05:46:06PM +0200, Aldy Hernandez wrote:
> On the true side of x == -0.0, we can't just blindly value propagate
> the -0.0 into every use of x because x could be +0.0 (or vice versa).
>
> With this change, we only allow the transformation if
> !HONOR_SIGNED_ZEROS or if the
On the true side of x == -0.0, we can't just blindly value propagate
the -0.0 into every use of x because x could be +0.0 (or vice versa).
With this change, we only allow the transformation if
!HONOR_SIGNED_ZEROS or if the range is known not to contain 0.
Will commit after tests complete.
14 matches
Mail list logo
