On Tue, 15 Nov 2022, Richard Sandiford wrote:
> "Andre Vieira (lists)" writes:
> > On 07/11/2022 11:05, Richard Biener wrote:
> >> On Fri, 4 Nov 2022, Andre Vieira (lists) wrote:
> >>
> >>> Sorry for the delay, just been reminded I still had this patch outstanding
> >>> from last stage 1.
"Andre Vieira (lists)" writes:
> On 07/11/2022 11:05, Richard Biener wrote:
>> On Fri, 4 Nov 2022, Andre Vieira (lists) wrote:
>>
>>> Sorry for the delay, just been reminded I still had this patch outstanding
>>> from last stage 1. Hopefully since it has been mostly reviewed it could go
>>> in
On 07/11/2022 14:56, Richard Biener wrote:
On Mon, 7 Nov 2022, Andre Vieira (lists) wrote:
On 07/11/2022 11:05, Richard Biener wrote:
On Fri, 4 Nov 2022, Andre Vieira (lists) wrote:
Sorry for the delay, just been reminded I still had this patch outstanding
from last stage 1. Hopefully
On Mon, 7 Nov 2022, Andre Vieira (lists) wrote:
>
> On 07/11/2022 11:05, Richard Biener wrote:
> > On Fri, 4 Nov 2022, Andre Vieira (lists) wrote:
> >
> >> Sorry for the delay, just been reminded I still had this patch outstanding
> >> from last stage 1. Hopefully since it has been mostly
On 07/11/2022 11:05, Richard Biener wrote:
On Fri, 4 Nov 2022, Andre Vieira (lists) wrote:
Sorry for the delay, just been reminded I still had this patch outstanding
from last stage 1. Hopefully since it has been mostly reviewed it could go in
for this stage 1?
I addressed the comments and
On Fri, 4 Nov 2022, Andre Vieira (lists) wrote:
> Sorry for the delay, just been reminded I still had this patch outstanding
> from last stage 1. Hopefully since it has been mostly reviewed it could go in
> for this stage 1?
>
> I addressed the comments and gave the slp-part of vectorizable_call
Sorry for the delay, just been reminded I still had this patch
outstanding from last stage 1. Hopefully since it has been mostly
reviewed it could go in for this stage 1?
I addressed the comments and gave the slp-part of vectorizable_call some
TLC to make it work.
I also changed
"Andre Vieira (lists)" writes:
> diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
> index
> 19e89ae502bc2f51db64667b236c1cb669718b02..3b0e4e0875b4392ab6833568b207580ef597a98f
> 100644
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -6191,6 +6191,15 @@ operands; otherwise, it may not.
>
>
On Mon, 10 Jan 2022, Andre Vieira (lists) wrote:
> Yeah seems I forgot to send the latest version, my bad.
>
> Bootstrapped on aarch64-none-linux.
>
> OK for trunk?
The match.pd part looks OK to me.
Thanks,
Richard.
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.md (ftrunc2): New
>
Yeah seems I forgot to send the latest version, my bad.
Bootstrapped on aarch64-none-linux.
OK for trunk?
gcc/ChangeLog:
* config/aarch64/aarch64.md (ftrunc2): New
pattern.
* config/aarch64/iterators.md (FRINTNZ): New iterator.
(frintnz_mode): New int attribute.
On Wed, 29 Dec 2021, Andre Vieira (lists) wrote:
> Hi Richard,
>
> Thank you for the review, I've adopted all above suggestions downstream, I am
> still surprised how many style things I still miss after years of gcc
> development :(
>
> On 17/12/2021 12:44, Richard Sandiford wrote:
> >
> >> @@
"Andre Vieira (lists)" writes:
> On 17/12/2021 12:44, Richard Sandiford wrote:
>>
>>> @@ -3252,16 +3257,31 @@ vectorizable_call (vec_info *vinfo,
>>> rhs_type = unsigned_type_node;
>>> }
>>>
>>> - int mask_opno = -1;
>>> + /* The argument that is not of the same type as the
Hi Richard,
Thank you for the review, I've adopted all above suggestions downstream,
I am still surprised how many style things I still miss after years of
gcc development :(
On 17/12/2021 12:44, Richard Sandiford wrote:
@@ -3252,16 +3257,31 @@ vectorizable_call (vec_info *vinfo,
"Andre Vieira (lists) via Gcc-patches" writes:
> On 22/11/2021 11:41, Richard Biener wrote:
>>
>>> On 18/11/2021 11:05, Richard Biener wrote:
This is a good shout and made me think about something I hadn't before... I
thought I could handle the vector forms later, but the problem is if
ping
On 25/11/2021 13:53, Andre Vieira (lists) via Gcc-patches wrote:
On 22/11/2021 11:41, Richard Biener wrote:
On 18/11/2021 11:05, Richard Biener wrote:
This is a good shout and made me think about something I hadn't
before... I
thought I could handle the vector forms later, but the
On 18/11/2021 11:05, Richard Biener wrote:
+ (if (!flag_trapping_math
+ && direct_internal_fn_supported_p (IFN_TRUNC, type,
+OPTIMIZE_FOR_BOTH))
+ (IFN_TRUNC @0)
#endif
does IFN_FTRUNC_INT preserve the same exceptions as
On 22/11/2021 11:41, Richard Biener wrote:
On 18/11/2021 11:05, Richard Biener wrote:
This is a good shout and made me think about something I hadn't before... I
thought I could handle the vector forms later, but the problem is if I add
support for the scalar, it will stop the vectorizer. It
On Mon, 22 Nov 2021, Andre Vieira (lists) wrote:
>
> On 18/11/2021 11:05, Richard Biener wrote:
> >
> > @@ -3713,12 +3713,21 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > trapping behaviour, so require !flag_trapping_math. */
> > #if GIMPLE
> > (simplify
> > - (float (fix_trunc @0))
> >
On 18/11/2021 11:05, Richard Biener wrote:
@@ -3713,12 +3713,21 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
trapping behaviour, so require !flag_trapping_math. */
#if GIMPLE
(simplify
- (float (fix_trunc @0))
- (if (!flag_trapping_math
- && types_match (type, TREE_TYPE (@0))
-
On Wed, 17 Nov 2021, Andre Vieira (lists) wrote:
>
> On 16/11/2021 12:10, Richard Biener wrote:
> > On Fri, 12 Nov 2021, Andre Simoes Dias Vieira wrote:
> >
> >> On 12/11/2021 10:56, Richard Biener wrote:
> >>> On Thu, 11 Nov 2021, Andre Vieira (lists) wrote:
> >>>
> Hi,
>
> This
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index
> 4035e061706793849c68ae09bcb2e4b9580ab7b6..62adbc4cb6bbbe0c856f9fbe451aee08f2dea3b5
> 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -7345,6 +7345,14 @@ (define_insn
On 16/11/2021 12:10, Richard Biener wrote:
On Fri, 12 Nov 2021, Andre Simoes Dias Vieira wrote:
On 12/11/2021 10:56, Richard Biener wrote:
On Thu, 11 Nov 2021, Andre Vieira (lists) wrote:
Hi,
This patch introduces two IFN's FTRUNC32 and FTRUNC64, the corresponding
optabs and mappings. It
On Fri, 12 Nov 2021, Andre Simoes Dias Vieira wrote:
>
> On 12/11/2021 10:56, Richard Biener wrote:
> > On Thu, 11 Nov 2021, Andre Vieira (lists) wrote:
> >
> >> Hi,
> >>
> >> This patch introduces two IFN's FTRUNC32 and FTRUNC64, the corresponding
> >> optabs and mappings. It also creates a
On 12/11/2021 10:56, Richard Biener wrote:
On Thu, 11 Nov 2021, Andre Vieira (lists) wrote:
Hi,
This patch introduces two IFN's FTRUNC32 and FTRUNC64, the corresponding
optabs and mappings. It also creates a backend pattern to implement them for
aarch64 and a match.pd pattern to idiom
On Thu, 11 Nov 2021, Andre Vieira (lists) wrote:
> Hi,
>
> This patch introduces two IFN's FTRUNC32 and FTRUNC64, the corresponding
> optabs and mappings. It also creates a backend pattern to implement them for
> aarch64 and a match.pd pattern to idiom recognize these.
> These IFN's (and optabs)
Hi,
This patch introduces two IFN's FTRUNC32 and FTRUNC64, the corresponding
optabs and mappings. It also creates a backend pattern to implement them
for aarch64 and a match.pd pattern to idiom recognize these.
These IFN's (and optabs) represent a truncation towards zero, as if
performed by
26 matches
Mail list logo
