[i386] A minor code clean-up: Use NULL_RTX instead of nullptr

My understanding is that GCC's preferred null value for rtx is NULL_RTX
(and for tree is NULL_TREE), and by being typed allows strict type checking,
and use with function polymorphism and template instantiation.
C++'s nullptr is preferred over NULL and 0 for pointer types that don't
have a defined null of the correct type.

This minor clean-up uses NULL_RTX consistently in i386-expand.cc.

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32}
with no new failures.  Ok for mainline?  Is my understanding correct?


2023-05-24  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
	* config/i386/i386.cc (ix86_convert_wide_int_to_broadcast):  Use
	NULL_RTX instead of nullptr.
	(ix86_convert_const_wide_int_to_broadcast): Likewise.
	(ix86_broadcast_from_constant): Likewise.
	(ix86_expand_vector_move): Likewise.
	(ix86_extract_perm_from_pool_constant): Likewise.


Thanks,
Roger
--

On Wed, 24 May 2023 18:54:06 +0100
"Roger Sayle" <roger@nextmovesoftware.com> wrote:

> My understanding is that GCC's preferred null value for rtx is NULL_RTX
> (and for tree is NULL_TREE), and by being typed allows strict type checking,
> and use with function polymorphism and template instantiation.
> C++'s nullptr is preferred over NULL and 0 for pointer types that don't
> have a defined null of the correct type.
> 
> This minor clean-up uses NULL_RTX consistently in i386-expand.cc.

Oh. Well, i can't resist cleanups :)

Given
$ cat /tmp/inp0.c ; echo EOF
rtx myfunc (int i, int j)
{
  rtx ret;
  if (i)
    return NULL;
  if (j)
   ret = NULL;
  if (ret == NULL) {
    ret = NULL_RTX;
  }
  if (!ret)
    return (rtx)2;
  return NULL_RTX;
}
EOF
$ spatch --c++=11 --smpl-spacing --in-place --sp-file ~/coccinelle/rtx-null.0.cocci /tmp/inp0.c
init_defs_builtins: /usr/bin/../lib/coccinelle/standard.h
--- /tmp/inp0.c
+++ /tmp/cocci-output-76891-58af4a-inp0.c
@@ -2,10 +2,10 @@ rtx myfunc (int i, int j)
 {
   rtx ret;
   if (i)
-    return NULL;
+    return NULL_RTX;
   if (j)
-   ret = NULL;
-  if (ret == NULL) {
+   ret = NULL_RTX;
+  if (ret == NULL_RTX) {
     ret = NULL_RTX;
   }
   if (!ret)
HANDLING: /tmp/inp0.c
diff = 

So you if you would feel like, someone could
find ./ \( -name "testsuite" -o -name "contrib" -o -name "examples" -o -name ".git" -o -name "zlib" -o -name "intl" \) -prune -o \( -name "*.[chpx]*" -a -type f \) -exec spatch --c++=11 --smpl-spacing --in-place $opts --sp-file ~/coccinelle/rtx-null.0.cocci {} \;
with the attached rtx-null coccinelle script.
(and handle nullptr too, and the same game for tree)

Just a thought..

On Thu, 25 May 2023 18:58:04 +0200
Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:

> On Wed, 24 May 2023 18:54:06 +0100
> "Roger Sayle" <roger@nextmovesoftware.com> wrote:
> 
> > My understanding is that GCC's preferred null value for rtx is NULL_RTX
> > (and for tree is NULL_TREE), and by being typed allows strict type checking,
> > and use with function polymorphism and template instantiation.
> > C++'s nullptr is preferred over NULL and 0 for pointer types that don't
> > have a defined null of the correct type.
> > 
> > This minor clean-up uses NULL_RTX consistently in i386-expand.cc.  
> 
> Oh. Well, i can't resist cleanups :)

> (and handle nullptr too, and the same game for tree)

so like the attached. And
sed -e 's/RTX/TREE/g' -e 's/rtx/tree/g' \
  < ~/coccinelle/gcc-rtx-null.0.cocci \
  > ~/coccinelle/gcc-tree-null.0.cocci

I do not know if we want to shorten explicit NULL comparisons.
 foo == NULL => !foo and foo != NULL => foo
Left them alone in the form they were written.

See the attached result of the rtx hunks, someone would have to build
it and hack git-commit-mklog.py --changelog 'Use NULL_RTX.'
to print("{}.".format(random.choice(['Ditto', 'Same', 'Likewise']))) ;)

> 
> Just a thought..

cheers,

plonk.

On 26 May 2023 10:31:51 CEST, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
>On Thu, 25 May 2023 18:58:04 +0200
>Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
>
>> On Wed, 24 May 2023 18:54:06 +0100
>> "Roger Sayle" <roger@nextmovesoftware.com> wrote:
>> 
>> > My understanding is that GCC's preferred null value for rtx is NULL_RTX
>> > (and for tree is NULL_TREE), and by being typed allows strict type checking,
>> > and use with function polymorphism and template instantiation.
>> > C++'s nullptr is preferred over NULL and 0 for pointer types that don't
>> > have a defined null of the correct type.
>> > 
>> > This minor clean-up uses NULL_RTX consistently in i386-expand.cc.  
>> 
>> Oh. Well, i can't resist cleanups :)
>
>> (and handle nullptr too, and the same game for tree)
>
>so like the attached. And
>sed -e 's/RTX/TREE/g' -e 's/rtx/tree/g' \
>  < ~/coccinelle/gcc-rtx-null.0.cocci \
>  > ~/coccinelle/gcc-tree-null.0.cocci
>
>I do not know if we want to shorten explicit NULL comparisons.
> foo == NULL => !foo and foo != NULL => foo
>Left them alone in the form they were written.
>
>See the attached result of the rtx hunks, someone would have to build

I've bootstrapped and regtested the hunks for rtx as cited up-thread without regressions (as expected).

I know everybody is busy, but I'd like to know if I should swap these out completely,   or postpone this until start of stage3 or next stage 1 or something.
I can easily keep these local to my personal pre-configure stage for my own amusement.

thanks,

>it and hack git-commit-mklog.py --changelog 'Use NULL_RTX.'
>to print("{}.".format(random.choice(['Ditto', 'Same', 'Likewise']))) ;)
>
>> 
>> Just a thought..
>
>cheers,

On Wed, 14 Jun 2023 21:14:02 +0200
Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:

> plonk.

ping^3

patch at
https://inbox.sourceware.org/gcc-patches/20230526103151.3a7f65d0@nbbrfq.loc/

I would regenerate it for rtx and/or tree, though, whatever you deem
desirable?

thanks

> 
> On 26 May 2023 10:31:51 CEST, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
> >On Thu, 25 May 2023 18:58:04 +0200
> >Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
> >  
> >> On Wed, 24 May 2023 18:54:06 +0100
> >> "Roger Sayle" <roger@nextmovesoftware.com> wrote:
> >>   
> >> > My understanding is that GCC's preferred null value for rtx is NULL_RTX
> >> > (and for tree is NULL_TREE), and by being typed allows strict type checking,
> >> > and use with function polymorphism and template instantiation.
> >> > C++'s nullptr is preferred over NULL and 0 for pointer types that don't
> >> > have a defined null of the correct type.
> >> > 
> >> > This minor clean-up uses NULL_RTX consistently in i386-expand.cc.    
> >> 
> >> Oh. Well, i can't resist cleanups :)  
> >  
> >> (and handle nullptr too, and the same game for tree)  
> >
> > so like the attached. And
> > sed -e 's/RTX/TREE/g' -e 's/rtx/tree/g' \
> >  < ~/coccinelle/gcc-rtx-null.0.cocci \  
> >  > ~/coccinelle/gcc-tree-null.0.cocci  
> >
> > I do not know if we want to shorten explicit NULL comparisons.
> > foo == NULL => !foo and foo != NULL => foo
> > Left them alone in the form they were written.
> >
> > See the attached result of the rtx hunks, someone would have to build  
> 
> I've bootstrapped and regtested the hunks for rtx as cited up-thread without regressions (as expected).
> 
> I know everybody is busy, but I'd like to know if I should swap these out completely,
> or postpone this until start of stage3 or next stage 1 or something.
> I can easily keep these local to my personal pre-configure stage for my own amusement.
> 
> thanks,
> 
> >it and hack git-commit-mklog.py --changelog 'Use NULL_RTX.'
> >to print("{}.".format(random.choice(['Ditto', 'Same', 'Likewise']))) ;)
> >  
> >> 
> >> Just a thought..  
> >
> >cheers,  
>