Re: MIPS Maintainer

[Maciej W. Rozycki]

Hi Chao-ying,

 Great to hear from you again!

>   We just wonder if you can sponsor me to become a MIPS maintainer, 
> because Wave Computing would like to continue supporting MIPS 
> architecture in GCC, although there are very few patches for MIPS 
> recently. Any feedback is welcome.

 Well, it's up to the GCC steering committee really to appoint maintainers 
, however you can post patches and help 
with getting reviews through right away.  There hasn't been much traffic 
with the MIPS port recently, but there has been some and it always helps 
to have someone provide input.

  Maciej

Re: Help with PR97872

[Prathamesh Kulkarni via Gcc]

On Mon, 7 Dec 2020 at 17:37, Hongtao Liu  wrote:
>
> On Mon, Dec 7, 2020 at 7:11 PM Prathamesh Kulkarni
>  wrote:
> >
> > On Mon, 7 Dec 2020 at 16:15, Hongtao Liu  wrote:
> > >
> > > On Mon, Dec 7, 2020 at 5:47 PM Richard Biener  wrote:
> > > >
> > > > On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> > > >
> > > > > On Mon, 7 Dec 2020 at 13:01, Richard Biener  wrote:
> > > > > >
> > > > > > On Mon, 7 Dec 2020, Prathamesh Kulkarni wrote:
> > > > > >
> > > > > > > On Fri, 4 Dec 2020 at 17:18, Richard Biener  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Fri, 4 Dec 2020, Prathamesh Kulkarni wrote:
> > > > > > > >
> > > > > > > > > On Thu, 3 Dec 2020 at 16:35, Richard Biener 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, 3 Dec 2020, Prathamesh Kulkarni wrote:
> > > > > > > > > >
> > > > > > > > > > > On Tue, 1 Dec 2020 at 16:39, Richard Biener 
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, 1 Dec 2020, Prathamesh Kulkarni wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > > For the test mentioned in PR, I was trying to see if 
> > > > > > > > > > > > > we could do
> > > > > > > > > > > > > specialized expansion for vcond in target when 
> > > > > > > > > > > > > operands are -1 and 0.
> > > > > > > > > > > > > arm_expand_vcond gets the following operands:
> > > > > > > > > > > > > (reg:V8QI 113 [ _2 ])
> > > > > > > > > > > > > (reg:V8QI 117)
> > > > > > > > > > > > > (reg:V8QI 118)
> > > > > > > > > > > > > (lt (reg/v:V8QI 115 [ a ])
> > > > > > > > > > > > > (reg/v:V8QI 116 [ b ]))
> > > > > > > > > > > > > (reg/v:V8QI 115 [ a ])
> > > > > > > > > > > > > (reg/v:V8QI 116 [ b ])
> > > > > > > > > > > > >
> > > > > > > > > > > > > where r117 and r118 are set to vector constants -1 
> > > > > > > > > > > > > and 0 respectively.
> > > > > > > > > > > > > However, I am not sure if there's a way to check if 
> > > > > > > > > > > > > the register is
> > > > > > > > > > > > > constant during expansion time (since we don't have 
> > > > > > > > > > > > > df analysis yet) ?
> > >
> > > It seems to me that all you need to do is relax the predicates of op1
> > > and op2 in vcondmn to accept const0_rtx and constm1_rtx. I haven't
> > > debugged it, but I see that vcondmn in neon.md only accepts
> > > s_register_operand.
> > >
> > > (define_expand "vcond"
> > >   [(set (match_operand:VDQW 0 "s_register_operand")
> > > (if_then_else:VDQW
> > >   (match_operator 3 "comparison_operator"
> > > [(match_operand:VDQW 4 "s_register_operand")
> > >  (match_operand:VDQW 5 "reg_or_zero_operand")])
> > >   (match_operand:VDQW 1 "s_register_operand")
> > >   (match_operand:VDQW 2 "s_register_operand")))]
> > >   "TARGET_NEON && (! || flag_unsafe_math_optimizations)"
> > > {
> > >   arm_expand_vcond (operands, mode);
> > >   DONE;
> > > })
> > >
> > > in sse.md it's defined as
> > > (define_expand "vcondu"
> > >   [(set (match_operand:V_512 0 "register_operand")
> > > (if_then_else:V_512
> > >   (match_operator 3 ""
> > > [(match_operand:VI_AVX512BW 4 "nonimmediate_operand")
> > >  (match_operand:VI_AVX512BW 5 "nonimmediate_operand")])
> > >   (match_operand:V_512 1 "general_operand")
> > >   (match_operand:V_512 2 "general_operand")))]
> > >   "TARGET_AVX512F
> > >&& (GET_MODE_NUNITS (mode)
> > >== GET_MODE_NUNITS (mode))"
> > > {
> > >   bool ok = ix86_expand_int_vcond (operands);
> > >   gcc_assert (ok);
> > >   DONE;
> > > })
> > >
> > > then we can get operands[1] and operands[2] as
> > >
> > > (gdb) p debug_rtx (operands[1])
> > >  (const_vector:V16QI [
> > > (const_int -1 [0x]) repeated x16
> > > ])
> > > (gdb) p debug_rtx (operands[2])
> > > (reg:V16QI 82 [ _2 ])
> > > (const_vector:V16QI [
> > > (const_int 0 [0]) repeated x16
> > > ])
> > Hi Hongtao,
> > Thanks for the suggestions!
> > However IIUC from vector extensions doc page, the result of vector
> > comparison is defined to be 0
> > or -1, so would it be better to canonicalize
> > x cmp y ? -1 : 0 to x cmp y, on GIMPLE itself during gimple-isel and
> > adjust targets if required ?
>
> Yes, it would be more straightforward to handle it in gimple isel, I
> would adjust the backend and testcase after you check in the patch.
Thanks! I have committed the attached patch in
3a6e3ad38a17a03ee0139b49a0946e7b9ded1eb1.

Regards,
Prathamesh
>
> > Alternatively, I could try fixing this in backend as you suggest above.
> >
> > Thanks,
> > Prathamesh
> > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Alternatively, should we add a target hook that 
> > > > > > > > > > > > > returns true if the
> > > > > > > > > > > > > result of vector comparison is set to all-ones or 
> > > > > > > > > > > > > all-zeros, and then
> > > > > > > > > > > > > use this hook in gimple ISEL to effectively turn 
> > > > > > > >

Re: [EXTERNAL]Re: MIPS Maintainer

[Chao-ying Fu]

Hi Maciej,

>  Great to hear from you again!

  It's great to hear from you, too!

> >   We just wonder if you can sponsor me to become a MIPS maintainer, 
> > because Wave Computing would like to continue supporting MIPS 
> > architecture in GCC, although there are very few patches for MIPS 
> > recently. Any feedback is welcome.

>  Well, it's up to the GCC steering committee really to appoint maintainers 
> , however you can post patches and help 
> with getting reviews through right away.  There hasn't been much traffic 
> with the MIPS port recently, but there has been some and it always helps 
> to have someone provide input.

  I got David Edelsohn's email and replied to him yesterday.
We have some small tweaks in GCC and can send the patches.
There is a big patch for nanoMIPS that stays as-is for long time.
It will take time to get the patch working against the latest code base,
if the community wants to include nanoMIPS in GCC.

  Thanks a lot!

Regards,
Chao-ying

Re: [EXTERNAL]Re: MIPS Maintainer

[David Edelsohn via Gcc]

On Tue, Dec 8, 2020 at 12:52 PM Chao-ying Fu  wrote:
>
> Hi Maciej,
>
> >  Great to hear from you again!
>
>   It's great to hear from you, too!
>
> > >   We just wonder if you can sponsor me to become a MIPS maintainer,
> > > because Wave Computing would like to continue supporting MIPS
> > > architecture in GCC, although there are very few patches for MIPS
> > > recently. Any feedback is welcome.
>
> >  Well, it's up to the GCC steering committee really to appoint maintainers
> > , however you can post patches and help
> > with getting reviews through right away.  There hasn't been much traffic
> > with the MIPS port recently, but there has been some and it always helps
> > to have someone provide input.
>
>   I got David Edelsohn's email and replied to him yesterday.
> We have some small tweaks in GCC and can send the patches.
> There is a big patch for nanoMIPS that stays as-is for long time.
> It will take time to get the patch working against the latest code base,
> if the community wants to include nanoMIPS in GCC.

You shouldn't ask to be a co-maintainer solely because you want to
contribute patches, or patches that are specific to your specific
implementation of Mips.  You already can contribute patches.
Maintainers / reviewers for a port review all patches relevant to the
port, their appointment is to the community role, not a role for their
specific vendor.

Thanks, David

How do I print the name of a variable created with create_tmp_var_raw

[Thomas Koenig via Gcc]

Hi,

I would like to know the name of a variable created with
create_tmp_var_raw, but it is not clear to my how to do it.

gimple_decl_printable_name sounded like a likely candidate,
but that just returns a null pointer.  Any combination of
IDENTIFIER_POINTER and DECL_NAME that I tried also led to
checking errors or segfaults.

More specifically,

diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index f1c8f0ee17f..11043406840 100644
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -96,7 +96,7 @@ gfc_create_var_np (tree type, const char *prefix)
   tree t;

   t = create_tmp_var_raw (type, prefix);
-
+  dprintf (2, "%s\n", IDENTIFIER_POINTER (DECL_NAME (t)));
   /* No warnings for anonymous variables.  */
   if (prefix == NULL)
 TREE_NO_WARNING (t) = 1;

which I thought should work according to the documentation I've
read resulted in a segfault.

Any pointers? Is there a magic incantation that I am missing?

Best regards

Thomas

Re: How do I print the name of a variable created with create_tmp_var_raw

[Tobias Burnus]

Hi Thomas,

On 08.12.20 19:34, Thomas Koenig via Fortran wrote:

I would like to know the name of a variable created with
create_tmp_var_raw, but it is not clear to my how to do it.
...
   t = create_tmp_var_raw (type, prefix);
-
+  dprintf (2, "%s\n", IDENTIFIER_POINTER (DECL_NAME (t)));


I think that's okay. However:

Do you have a prefix or not?

If there is no prefix, DECL_NAME (t) == NULL.

If there is a prefix, the name is create_tmp_var_name (prefix),
which is (on most systems)   "%s.%d", prefix, tmp_var_id_num++

Otherwise, the D.1234 you see in the dump is mostly the result of
"D.%u", DECL_UID (t).

I hope it helps,

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

Re: How do I print the name of a variable created with create_tmp_var_raw

[Thomas Koenig via Gcc]

Hi Tobias,


On 08.12.20 19:34, Thomas Koenig via Fortran wrote:

I would like to know the name of a variable created with
create_tmp_var_raw, but it is not clear to my how to do it.
...
   t = create_tmp_var_raw (type, prefix);
-
+  dprintf (2, "%s\n", IDENTIFIER_POINTER (DECL_NAME (t)));


I think that's okay. However:

Do you have a prefix or not?

If there is no prefix, DECL_NAME (t) == NULL.

If there is a prefix, the name is create_tmp_var_name (prefix),
which is (on most systems)   "%s.%d", prefix, tmp_var_id_num++

Otherwise, the D.1234 you see in the dump is mostly the result of
"D.%u", DECL_UID (t).


Yes, this clears up things.  Thanks!

I am currently trying to figure out better ways of debugging
generated code (PR 90207) and one thing is to make intermediate
variables visible to the debugger, of course under control of
a special flag.  The dot is of course not a good choice beause
gdb will not print a variable called S.0, but maybe a @ will work.

Or, less amitious, sometimes it is hard to see by which path a
certain variable is generated. Being able to set a breakpoint
where a certain variable is being generated can help a lot.

Best regards

Thomas

Re: RISC-V -menable-experimental-extensions option

[Jeff Law via Gcc]

On 12/7/20 6:06 PM, Jim Wilson wrote:
> I'm not aware of any other target that has a similar feature, so I thought
> a bit of discussion first might be useful.
>
> For most ISAs, there is one organization that owns it, and does development
> internally, in private.  For RISC-V, the ISA is owned by RISC-V
> International which has no developers.  The development all happens
> externally, in public, spread across at least a dozen different
> organizations.  So we have the problem of coordinating this work,
> especially for draft versions of extensions.  So we would like to add
> support for draft extensions to mainline, controlled by a
> -menable-experimental-extensions option.  For features enabled by this
> option, there would be no guarantee that the next compiler release is
> compatible with the previous one, since the draft extension may change in
> incompatible ways.
>
> LLVM already has support for this option.
> http://lists.llvm.org/pipermail/llvm-dev/2020-January/138364.html
> https://reviews.llvm.org/D73891
>
> We are still discussing the details of how this will work.  We may want to
> limit this to 'stable" draft extensions, and put the unstable drafts on a
> vendor branch.
>
> We have been doing work on branches in the github.com riscv tree, but there
> are issues with tracking who has copyright assignments, issues with
> identifying who exactly a github user actually is, and issues with getting
> the right set of people right access to the trees.  These won't be problems
> if we are using the FSF trees instead.
>
> We want this draft extension support on mainline for the same reasons that
> the LLVM developers do, to ensure that everyone is working in the same
> branch in the upstream tree.  And it is easiest to do that if that branch
> is mainline.
>
> This is just a binutils and gcc proposal at the moment, but we might need
> something on the gdb side later, like a
>   set riscv experimental-extensions 1
> or whatever command to enable support for draft extensions.
It seems reasonable to me.  The worst thing that happens is you find
it's not terribly better than what we're currently doing and we scramble
the process again to work better.

jeff