On Wed, Sep 25, 2024 at 12:12 PM Kugan Vivekanandarajah
wrote:
>
> Hi Richard,
>
> > On 24 Sep 2024, at 6:16 pm, Richard Biener
> > wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Mon, Sep 23, 2024 at 10:52 AM Kugan Vivekanandarajah
> > wrote:
> >>
> >> Hi
On Mon, Sep 23, 2024 at 10:52 AM Kugan Vivekanandarajah
wrote:
>
> Hi Richard,
>
> > On 20 Sep 2024, at 8:11 pm, Richard Biener
> > wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Fri, Sep 20, 2024 at 10:23 AM Kugan Vivekanandarajah
> > wrote:
> >>
> >> Hi
On Fri, Sep 20, 2024 at 10:23 AM Kugan Vivekanandarajah
wrote:
>
> Hi Richard,
>
> > On 17 Sep 2024, at 7:36 pm, Richard Biener
> > wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Tue, Sep 17, 2024 at 10:31 AM Kugan Vivekanandarajah
> > wrote:
> >>
> >> Hi
Hi Richard,
> On 17 Sep 2024, at 7:36 pm, Richard Biener wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Tue, Sep 17, 2024 at 10:31 AM Kugan Vivekanandarajah
> wrote:
>>
>> Hi Richard,
>>
>>> On 10 Sep 2024, at 9:33 pm, Richard Biener
>>> wrote:
>>>
>>> External em
On Tue, Sep 17, 2024 at 10:31 AM Kugan Vivekanandarajah
wrote:
>
> Hi Richard,
>
> > On 10 Sep 2024, at 9:33 pm, Richard Biener
> > wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Thu, Sep 5, 2024 at 3:19 AM Kugan Vivekanandarajah
> > wrote:
> >>
> >> Than
Hi Richard,
> On 10 Sep 2024, at 9:33 pm, Richard Biener wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Thu, Sep 5, 2024 at 3:19 AM Kugan Vivekanandarajah
> wrote:
>>
>> Thanks for the explanation.
>>
>>
>>> On 2 Sep 2024, at 9:47 am, Andrew Pinski wrote:
>>>
On Thu, Sep 5, 2024 at 3:19 AM Kugan Vivekanandarajah
wrote:
>
> Thanks for the explanation.
>
>
> > On 2 Sep 2024, at 9:47 am, Andrew Pinski wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Sun, Sep 1, 2024 at 4:27 PM Kugan Vivekanandarajah
> > wrote:
> >>
Thanks for the explanation.
> On 2 Sep 2024, at 9:47 am, Andrew Pinski wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Sun, Sep 1, 2024 at 4:27 PM Kugan Vivekanandarajah
> wrote:
>>
>> Hi Andrew.
>>
>>> On 28 Aug 2024, at 2:23 pm, Andrew Pinski wrote:
>>>
>>> Exter
On Sun, Sep 1, 2024 at 4:27 PM Kugan Vivekanandarajah
wrote:
>
> Hi Andrew.
>
> > On 28 Aug 2024, at 2:23 pm, Andrew Pinski wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Tue, Aug 27, 2024 at 8:54 PM Kugan Vivekanandarajah
> > wrote:
> >>
> >> Hi Richard,
gt;>>>>>
>>>>>>>>>> && !TYPE_UNSIGNED (TREE_TYPE (@2))
>>>>>>>>>> && ((element_precision (TREE_TYPE (@1))
>>>>>>>>>> < element_precision (TREE_TYPE (@0))
>
seeing: Note that the @2 for these are
> >>>>>>>> unsigned.
> >>>>>>>
> >>>>>>> I see, so we rely on @1 being the signed equivalent of @2 which might
> >>>>>>> or
> >>>>>>> might not be signed. I gues
t;>>
>>>>>>>> However with this, I am seeing: Note that the @2 for these are
>>>>>>>> unsigned.
>>>>>>>
>>>>>>> I see, so we rely on @1 being the signed equivalent of @2 which
ter then.
> >>>>>
> >>>>>
> >>>>>> && bitwise_equal_p (@1, @2))
> >>>>>> (if (TYPE_UNSIGNED (type))
> >>>>>>(absu:type @2)
> >>>>>>(abs @2)
> >>>>>
; (simplify
>>>>>> (cnd (cmp (convert?@0 @1) zerop) @2 (negate @2))
>>>>>> (if (!HONOR_SIGNED_ZEROS (TREE_TYPE (@1))
>>>>>> && !TYPE_UNSIGNED (TREE_TYPE (@1))
>>>>>
>>>>> Oh, I mis-read this as
>>> || operand_equal_p (@1, @0)))
> >>>
> >>> which means <= might be better then.
> >>>
> >>>
> >>>>&& bitwise_equal_p (@1, @2))
> >>>>(if (TYPE_UNSIGNED (type))
> >>
er then.
>>>
>>>
>>>>&& bitwise_equal_p (@1, @2))
>>>>(if (TYPE_UNSIGNED (type))
>>>> (absu:type @2)
>>>> (abs @2)
>>>>
>>>> However with this, I am seeing: Note that the @2 fo
< element_precision (TREE_TYPE (@0))
> >> || operand_equal_p (@1, @0)))
> >
> > which means <= might be better then.
> >
> >
> >> && bitwise_equal_p (@1, @2))
> >> (if (TYPE_UNSIGNED (type))
> >> (abs
IGNED (TREE_TYPE (@1))
>
> Oh, I mis-read this as unsigned, so this makes the conversions
> to always sign-extend which means it's important to ensure
> the type of @0 is also signed.
>
>> && !TYPE_UNSIGNED (TREE_TYPE (@2))
>> &
recision case should have been stripped anyway.
> >
> > You can use element_precision for both vector and non-vector so I think this
> > should simplify to just checking element_precision.
> >
> > + (absu:type @1)
> > + (abs @1)
> >
> > I still think this needs to be @2 for ty
nslate to:
/* (type)A >=/> 0 ? A : -A same as abs (A) */
(for cmp (ge gt)
(simplify
(cnd (cmp (convert?@0 @1) zerop) @2 (negate @2))
(if (!HONOR_SIGNED_ZEROS (TREE_TYPE (@1))
&& !TYPE_UNSIGNED (TREE_TYPE (@1))
&& !TYPE_UNSIGNED (TREE_TYPE (@2))
)
+ <= element_precision (TREE_TYPE (@0)))
+ || (!VECTOR_TYPE_P (TREE_TYPE (@0))
+ && (TYPE_PRECISION (TREE_TYPE (@1))
+ <= TYPE_PRECISION (TREE_TYPE (@0)
... you make the precision strictly larger. With both unsigned the same
- (absu:type @0)
- (abs @0)
+ (absu:type @1)
+ (abs @1)
Changing the @1 to @2 is resulting in failures. Existing tests like the
following would be optimized away in this case.
```
unsigned abs_with_convert0 (int x)
{
unsigned int y = x;
if (x < 0)
y = -y;
return y;
}
```
This follows the same intent as the
;
> ```
> And forwprop using match is able to do:
> ```
> Applying pattern match.pd:6306, gimple-match-10.cc:19843
> gimple_simplified to _4 = ABS_EXPR ;
> Removing dead stmt:_1 = a_2(D) > { 0, 0 };
> Removing dead stmt:na_3 = -a_2(D);
> ```
> (replace int with float and add -fno-si
vector(2) intD.9 _4;
na_3 = -a_2(D);
_1 = a_2(D) > { 0, 0 };
_4 = VEC_COND_EXPR <_1, a_2(D), na_3>;
```
And forwprop using match is able to do:
```
Applying pattern match.pd:6306, gimple-match-10.cc:19843
gimple_simplified to _4 = ABS_EXPR ;
Removing dead stmt:_1 = a_2(D) > { 0, 0 };
Removing dead stmt
. Also, we dont seem to generate (cmp @0 zerop). Am I
missing it completely?
Thanks,
Kugan
>
> >
> > >
> > > + (absu:type @1)
> > > + (abs @1)
> > >
> > > I think this should use @2 now.
> > I will change this.
> >
@2 now.
> I will change this.
>
> Thanks,
> Kugan
>
> >
> > > Thanks.
> > > Kugan
> > > >
> > > > (like what is in gcc.dg/c11-floatn-3.c and others).
> > > >
> > > > Other than that it looks good but I can
t; >
> > > Thanks,
> > > Andrew Pinski
> > >
> > > >
> > > > Signed-off-by: Kugan Vivekanandarajah
> > > >
> > > > Bootstrapped and regression test on aarch64-linux-gnu. Is this OK for
> > > > trunk?
> > > > Tha
-3.c and others).
> >
> > Other than that it looks good but I can't approve it.
> >
> > Thanks,
> > Andrew Pinski
> >
> > >
> > > Signed-off-by: Kugan Vivekanandarajah
> > >
> > > Bootstrapped and regression test on aarch6
Pinski
> > Sent: Monday, 15 July 2024 5:30 AM
> > To: Kugan Vivekanandarajah
> > Cc: gcc-patches@gcc.gnu.org ;
> > richard.guent...@gmail.com
> > Subject: Re: [PATCH] MATCH: add abs support for half float
> >
> > External email: Use caution opening links or
t; From: Andrew Pinski
> Sent: Monday, 15 July 2024 5:30 AM
> To: Kugan Vivekanandarajah
> Cc: gcc-patches@gcc.gnu.org ;
> richard.guent...@gmail.com
> Subject: Re: [PATCH] MATCH: add abs support for half float
>
> External email: Use caution opening links or attachments
>
: [PATCH] MATCH: add abs support for half float
External email: Use caution opening links or attachments
On Sun, Jul 14, 2024 at 1:12 AM Kugan Vivekanandarajah
wrote:
>
> This patch extends abs detection in matched for half float.
>
> Bootstrapped and regression test on aarch64-linux-gnu
On Sun, Jul 14, 2024 at 1:12 AM Kugan Vivekanandarajah
wrote:
>
> This patch extends abs detection in matched for half float.
>
> Bootstrapped and regression test on aarch64-linux-gnu. Is this OK for trunk?
This is basically this pattern:
```
/* A >=/> 0 ? A : -Asame as abs (A) */
(for cmp
32 matches
Mail list logo
