Opt out

Clyde Bazile bazileclyde@gmail.com
Wed Mar 24 18:20:38 GMT 2021


On Wed, Mar 24, 2021, 1:57 AM <gcc-patches-request@gcc.gnu.org> wrote:

> Send Gcc-patches mailing list submissions to
>         gcc-patches@gcc.gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://gcc.gnu.org/mailman/listinfo/gcc-patches
> or, via email, send a message with subject or body 'help' to
>         gcc-patches-request@gcc.gnu.org
>
> You can reach the person managing the list at
>         gcc-patches-owner@gcc.gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Gcc-patches digest..."
> Today's Topics:
>
>    1. Re: [PATCH v2 0/5] RISC-V big endian support (Jim Wilson)
>    2. Re: [PATCH] AIX struct alignment (PR 99557) (David Edelsohn)
>    3. [wwwdoc] gcc-11/changes: Document RISC-V changes (Kito Cheng)
>    4. [PATCH] rs6000: Correct Power8 cost of l2 cache size
>       [PR97329] (Xionghu Luo)
>    5. Employee Status Live Tracking App (Anushree)
>    6. [PATCH] rs6000: Don't generate IFN VEC_SET for m32 [PR99718]
>       (Xionghu Luo)
>
>
>
> ---------- Forwarded message ----------
> From: Jim Wilson <jimw@sifive.com>
> To: Kito Cheng <kito.cheng@gmail.com>
> Cc: Marcus Comstedt <marcus@mc.pp.se>, GCC Patches <
> gcc-patches@gcc.gnu.org>
> Bcc:
> Date: Tue, 23 Mar 2021 15:52:46 -0700
> Subject: Re: [PATCH v2 0/5] RISC-V big endian support
> On Fri, Mar 19, 2021 at 9:22 AM Kito Cheng via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
> > On Mon, Mar 15, 2021 at 5:42 AM Marcus Comstedt <marcus@mc.pp.se> wrote:
> > > I've now delved a bit deeper into the failure of the testcase
> > > gcc.c-torture/compile/pr35318.c on big endian RV32.
> >
>
> Looking at this testcase, I think this is triggering undefined behavior for
> extended asms.
>
> We have an SImode integer constant 8, a DFmode input/output, a 0
> constraint that matches the input to output, and then a % commutative
> operator that lets us swap operands, except once we swap operands we are
> now trying to force SImode and DFmode values to match via the 0 constraint
> which is unreasonable, plus a m constraint that then forces an input to
> memory.  It works by accident for little-endian because we reload the +0
> word of the double and it is still considered the same operand, and it
> fails for big-endian by accident because we reload the +4 word of the
> double and now it is considered a different operand.
>
> If I change the "8" to "(double)8" or "8.0" then the testcase works for
> both big and little endian, as now we have only DFmode values.
>
> I tried ppc-eabi and ppcle-eabi to see what happens there, and the main
> difference is that it chooses the 1 alternative in both cases.  However,
> for RISC-V, we choose the 0 alternative with operands swapped.  The reason
> for this is that we have a DFmode pseudo that wants an FP reg for a load,
> and the same pseudo wants a general reg in the asm, and rv32gc does not
> have an instruction to move directly between 64-bit FP regs and 32-bit
> general regs, so it gets put in memory as the lowest cost option.  That
> then leads to the case that alt 0 with swapped operands has the lowest
> cost, except this case is the invalid case that tries to match SImode and
> DFmode operands with 0 and m constraints and fails.
>
> To summarize, I think that there are two problems here.
> 1) The testcase is invalid, and can be fixed by changing the "8" to
> "(double)8" or "8.0" to ensure that we have a double constant that matches
> the type of the other operands.
> 2) GCC should be giving an error for an asm like this rather than an ICE.
> Note that if I manually swap the operands and remove the % I get
> void
> foo ()
> {
>   double x = 4, y;
>   __asm__ volatile ("" : "=r" (x), "=r" (y) : "0" (8), "m" (x));
> }
> which fails with an ICE for big-endian ppc exactly the same as it does for
> big-endian RISC-V.  We should be generating an error here rather than an
> ICE.
>
> Jim
>
>
>
>
> ---------- Forwarded message ----------
> From: David Edelsohn <dje.gcc@gmail.com>
> To: Richard Biener <richard.guenther@gmail.com>
> Cc: GCC Patches <gcc-patches@gcc.gnu.org>
> Bcc:
> Date: Tue, 23 Mar 2021 22:03:12 -0400
> Subject: Re: [PATCH] AIX struct alignment (PR 99557)
> On Mon, Mar 22, 2021 at 4:10 AM Richard Biener
> <richard.guenther@gmail.com> wrote:
>
> > Oh, and for a type like
> >
> >  struct { struct { struct { ... { double x; } } } } } };
> >
> > the layout now looks quadratic in work (each field layout will look at
> > the nest rooted at it
> > up to the bottom).  It looks to me as we require(?) the field types to
> > be laid out and thus
> > at least an early out checking the type alignment to be >= 64 can work?
>
> rs6000_special_round_type_align and rs6000_special_adjust_field_align
> both can have early exits to handle some easy cases.  Thanks for
> pointing that out.
>
> struct A { struct { struct { ... { double x; } } } };
> struct B { struct A; struct A; struct A; struct A; ...; };
>
> is a particularly ugly situation.
>
> When I originally had implemented this in GCC, the recursive nature of
> the requirement was not clear. Changing the alignment for a type
> (struct) in two different contexts (bare versus member) is bizarre,
> but that is what IBM XL compilers implement.
>
> If this becomes a time-sink for for in real use cases, one could
> create a side cache of the type with the previously calculated
> alignment value.  Or are there some preferred, available flag bit in
> the tree that can record that the type alignment has been checked and
> either use TYPE_ALIGN or use 32?  Maybe protected_flag or
> side_effects_flag or nothrow_flag?
>
> Thanks, David
>
>
>
>
> ---------- Forwarded message ----------
> From: Kito Cheng <kito.cheng@sifive.com>
> To: gcc-patches@gcc.gnu.org, kito.cheng@gmail.com, jimw@sifive.com
> Cc: Kito Cheng <kito.cheng@sifive.com>
> Bcc:
> Date: Wed, 24 Mar 2021 11:20:21 +0800
> Subject: [wwwdoc] gcc-11/changes: Document RISC-V changes
> ---
>  htdocs/gcc-11/changes.html | 32 +++++++++++++++++++++++++++++++-
>  1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
> index 69869309..ec136349 100644
> --- a/htdocs/gcc-11/changes.html
> +++ b/htdocs/gcc-11/changes.html
> @@ -688,7 +688,37 @@ a work-in-progress.</p>
>    </li>
>  </ul>
>
> -<!-- <h3 id="riscv">RISC-V</h3> -->
> +<h3 id="riscv">RISC-V</h3>
> +<ul>
> +  <li>Support big-endian for RISC-V, thanks to Marcus Comstedt.</li>
> +  <li>Implement new style of architecture extension test macros,
> +      each architecture extension has corresponding feature test macro,
> which
> +      could use to test its existence and version information.
> +  </li>
> +  <li>Legacy architecture extension test macro like
> <code>__riscv_atomic</code>,
> +      but it will still supported for at least 2 release cycles.
> +  </li>
> +  <li>Support IFUNC for <code>riscv*-*-linux*</code>.</li>
> +  <li>Introduce <code>--with-multilib-generator</code> to configure time
> option,
> +      this option could flexible config multi-lib settings, syntax is
> same as
> +      RISC-V's <code>multilib-generator</code>.
> +  </li>
> +  <li>Extend the sytax for <code>multilib-generator</code>, support
> expansion
> +      operator <code>*</code> to reduce the complexity of complicated
> multi-lib
> +      re-use rule.
> +  </li>
> +  <li>Support <code>-mcpu=*</code> option, the behavior is aligned to
> RISC-V
> +      clang/LLVM, it will set pipeline model and architecture extension,
> like
> +      <code>-mtune=*</code> plus <code>-march=*</code>.
> +  </li>
> +  <li>Support for TLS stack protector canary access, thanks to Cooper Qu.
> +  </li>
> +  <li>Support <code>__builtin_thread_pointer</code> for RISC-V.</li>
> +  <li>Introduce <code>shorten_memrefs</code> optimization, which could
> reduce the
> +      code size for memory access, thanks to Craig Blackmore.
> +  </li>
> +</ul>
> +
>
>  <!-- <h3 id="rx">RX</h3> -->
>
> --
> 2.30.2
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Xionghu Luo <luoxhu@linux.ibm.com>
> To: gcc-patches@gcc.gnu.org
> Cc: segher@kernel.crashing.org, dje.gcc@gmail.com, wschmidt@linux.ibm.com,
> guojiufu@linux.ibm.com, linkw@gcc.gnu.org, Xionghu Luo <
> luoxhu@linux.ibm.com>
> Bcc:
> Date: Wed, 24 Mar 2021 00:43:26 -0500
> Subject: [PATCH] rs6000: Correct Power8 cost of l2 cache size [PR97329]
> l2 cache size for Power8 is 512kB, correct the copy paste error from
> Power7.
> Tested no performance change for SPEC2017.
>
> gcc/ChangeLog:
>
> 2021-03-24  Xionghu Luo  <luoxhu@linux.ibm.com>
>
>         * config/rs6000/rs6000.c (struct processor_costs): Change to
>         512.
> ---
>  gcc/config/rs6000/rs6000.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index 616dae35bae..34c4edae20e 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -1055,7 +1055,7 @@ struct processor_costs power8_cost = {
>    COSTS_N_INSNS (17),  /* ddiv */
>    128,                 /* cache line size */
>    32,                  /* l1 cache */
> -  256,                 /* l2 cache */
> +  512,                 /* l2 cache */
>    12,                  /* prefetch streams */
>    COSTS_N_INSNS (3),   /* SF->DF convert */
>  };
> --
> 2.25.1
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Anushree <anushree@field-activities.com>
> To: <gcc-patches@gcc.gnu.org>
> Cc:
> Bcc:
> Date: Wed, 24 Mar 2021 01:44:39 -0400
> Subject: Employee Status Live Tracking App
>
>
>
>
> Hi,
>
>
>
> I hope your day at work is extraordinarily wonderful..
>
>
>
> I am writing this email to introduce our product to your organization - All
> in one Field Service Management application.
>
>
>
> This application will help your organization to enhance your field
> employees' work-flow for better productivity.
>
>
>
> Time is running out!! Look @ 6 SECRETS TO EFFECTIVE FIELD SERVICE:
>
>
>
> 1. Remote attendance management
>
> 2. Schedule meetings online & view status (Completed/pending)
>
> 3. Track distance covered (Km) with Ge-offence
>
> 4. Notice mobile signal strength & battery level
>
> 5. Import reports in one click from cloud database
>
> 6. Pre-built analytics shows productivity level
>
>
>
> I'm also happy to arrange a brief web session to bring you up to the speed.
> Let me know if you've questions or want to schedule the time to talk.
>
> Hope to hear from you soon.
>
> Best Regards,
>
> Anushree
>
> 90666348OO
>
>
>
>
>
>
>
> If you do not wish to receive future emails from us, please reply as "opt
> out " in the subject line.
>
>
>
>
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Xionghu Luo <luoxhu@linux.ibm.com>
> To: gcc-patches@gcc.gnu.org
> Cc: segher@kernel.crashing.org, dje.gcc@gmail.com, wschmidt@linux.ibm.com,
> guojiufu@linux.ibm.com, linkw@gcc.gnu.org, jakub@redhat.com,
> richard.guenther@gmail.com, Xionghu Luo <luoxhu@linux.ibm.com>
> Bcc:
> Date: Wed, 24 Mar 2021 00:57:19 -0500
> Subject: [PATCH] rs6000: Don't generate IFN VEC_SET for m32 [PR99718]
> UNSPEC_SI_FROM_SF is not supported for -m32 caused ICE on P8BE-32bit,
> since P8 Vector and above doesn't have fast mechanism to move SFmode to
> SImode for m32, don't generate IFN VEC_SET for it.
>
> Tested pass on P8BE/LE {m32,m64}.
>
> gcc/ChangeLog:
>
> 2021-03-24  Xionghu Luo  <luoxhu@linux.ibm.com>
>
>         * config/rs6000/predicates.md (vec_set_index_operand): New
>         predicate.
>         * config/rs6000/vector.md: Use vec_set_index_operand.
> ---
>  gcc/config/rs6000/predicates.md | 6 ++++++
>  gcc/config/rs6000/vector.md     | 3 +--
>  2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/config/rs6000/predicates.md
> b/gcc/config/rs6000/predicates.md
> index 859af75dfbd..51184390d24 100644
> --- a/gcc/config/rs6000/predicates.md
> +++ b/gcc/config/rs6000/predicates.md
> @@ -1940,3 +1940,9 @@ (define_predicate "d_form_memory"
>
>    return !indexed_address (addr, mode);
>  })
> +
> +;; Return true if m64 on p8v and above for vec_set with variable index.
> +(define_predicate "vec_set_index_operand"
> + (if_then_else (match_test "TARGET_P8_VECTOR && TARGET_DIRECT_MOVE_64BIT")
> +  (match_operand 0 "reg_or_cint_operand")
> +  (match_operand 0 "const_int_operand")))
> diff --git a/gcc/config/rs6000/vector.md b/gcc/config/rs6000/vector.md
> index e5191bd1424..c9ed5adfa4c 100644
> --- a/gcc/config/rs6000/vector.md
> +++ b/gcc/config/rs6000/vector.md
> @@ -1227,7 +1227,7 @@ (define_expand "vec_init<mode><VEC_base_l>"
>  (define_expand "vec_set<mode>"
>    [(match_operand:VEC_E 0 "vlogical_operand")
>     (match_operand:<VEC_base> 1 "register_operand")
> -   (match_operand 2 "reg_or_cint_operand")]
> +   (match_operand 2 "vec_set_index_operand")]
>    "VECTOR_MEM_ALTIVEC_OR_VSX_P (<MODE>mode)"
>  {
>    rs6000_expand_vector_set (operands[0], operands[1], operands[2]);
> @@ -1505,7 +1505,6 @@ (define_expand "vashr<mode>3"
>  ; is to allow us to use a code iterator, but not completely list all of
> the
>  ; vector rotates, etc. to prevent canonicalization
>
> -
>  (define_expand "reduc_<VEC_reduc:VEC_reduc_name>_scal_<VEC_F:mode>"
>    [(match_operand:<VEC_base> 0 "register_operand")
>     (VEC_reduc:VEC_F (match_operand:VEC_F 1 "vfloat_operand")
> --
> 2.25.1
>
>
>


More information about the Gcc-patches mailing list