>> +static rtx
>> +riscv_gen_unsigned_xmode_reg (rtx x, machine_mode mode)
>> +{
>> + if (!CONST_INT_P (x))
>> +return gen_lowpart (Xmode, x);
>> +
>> + rtx xmode_x = gen_reg_rtx (Xmode);
>> + HOST_WIDE_INT cst = INTVAL (x);
>> +
>> + emit_move_insn (xmode_x, x);
>> +
>> + int xmode_bits =
On 8/13/24 9:47 PM, Li, Pan2 wrote:
+static rtx
+riscv_gen_unsigned_xmode_reg (rtx x, machine_mode mode)
+{
+ if (!CONST_INT_P (x))
+return gen_lowpart (Xmode, x);
+
+ rtx xmode_x = gen_reg_rtx (Xmode);
+ HOST_WIDE_INT cst = INTVAL (x);
+
+ emit_move_insn (xmode_x, x);
+
+ int xmode_b
On 8/13/24 11:18, Andrew Carlotti wrote:
I'm still waiting for review for this patch. I've asked Richard
Sandiford about it, and he'd like a docs maintainer to review the
patch (so I've cc'd the rest of them now as well).
I'm sorry, I've seen this patch go by before, but every time I've looked
On 8/12/24 10:12 AM, Xianmiao Qu wrote:
The previous patch:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d8a6945c6ea22efa4d5e42fe1922d2b27953c8cd
aimed to eliminate redundant MOV instructions by removing calling
emit_clobber in lower-subreg.cc's resolve_simple_move.
First, I found that anoth
On 8/12/24 8:09 PM, Li, Pan2 wrote:
Isn't this wrong for SImode on rv64? It seems to me the right test is
mode != word_mode?
Assuming that works, it's OK for the trunk.
Thanks Jeff, Simode version of test file doesn't have this issue. Thus, only HI
and QI here.
I will add a new test for SI
On 8/12/24 4:45 PM, Mark Harmstone wrote:
Initialize last_type to 0 to silence two spurious maybe-uninitialized warnings.
We issue an LF_INDEX continuation subtype for any LF_FIELDLISTs that
overflow, so LF_INDEXes will always have a subtype preceding them (and
thus last_type will always be se
On 8/12/24 2:31 PM, Mark Wielaard wrote:
The testcase uses -march=rv64gcv and dg-do run, so should be
restricted to a riscv_v target.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr116202-run-1.c (dg-do run):
Add target riscv_v.
OK
jeff
On 8/12/24 6:24 PM, Mark Harmstone wrote:
Outputs CodeView S_LDATA32 symbols, for static variables within
functions, along with S_BLOCK32 and S_END for the beginning and end of
lexical blocks.
gcc/
* dwarf2codeview.cc (enum cv_sym_type): Add S_END and S_BLOCK32.
(write_local_s
> How specifically is it avoided for SI? ISTM it should have the exact
> same problem with a constant like 0x8000 in SImode on rv64 which is
> going to be extended to 0x8000.
HI and QI need some special handling for sum. For example, for HImode.
65535 + 2 = 65537, when compare
> But you're shifting a REG, not a CONST_INT.
I see, we can make a QImode REG to be moved to, and then zero_extend.
Thanks Jeff for enlightening me, and will send v3 for this.
Pan
-Original Message-
From: Jeff Law
Sent: Wednesday, August 14, 2024 11:52 AM
To: Li, Pan2 ; gcc-patches@gcc.
On 8/13/24 7:52 PM, Patrick Palka wrote:
On Tue, 13 Aug 2024, Jason Merrill wrote:
On 8/12/24 10:01 PM, Patrick Palka wrote:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14?
-- >8 --
In r15-2210 we got rid of the unnecessary cast to lvalue reference when
passing *this to the pr
Hi Harald,
I had a hard time to figure why this is correct, when gfc_array_size() returned
false, but now I get it. Ok to commit.
- Andre
On Tue, 13 Aug 2024 21:25:31 +0200
Harald Anlauf wrote:
> Dear all,
>
> while running f951 under valgrind on testcase gfortran.dg/sizeof_6.f90
> I found two
Hi,
Am 14. August 2024 00:38:53 MESZ schrieb Xavier Del Campo Romero
:
> I have been overseeing these last emails - thank you very much for your
> efforts, Alex! I did not reply until now because I do not have prior
> experience with gcc internals, so my feedback would probably have not
> been t
This patch is to fix the bug (BugId:116305) introduced by the commit
bd93ef for risc-v target.
The commit bd93ef changes the chunk_num from 1 to TARGET_MIN_VLEN/128
if TARGET_MIN_VLEN is larger than 128 in riscv_convert_vector_bits. So
it changes the value of BYTES_PER_RISCV_VECTOR. For example, b
On Wed, Aug 14, 2024 at 03:51:55AM +0100, Sam James wrote:
>
> LGTM.
>
> thanks,
> sam
It's committed, thanks.
BR,
Xianmiao
Hi,
This patch adds const0 move checking for CLEAR_BY_PIECES. The original
vec_duplicate handles duplicates of non-constant inputs. But 0 is a
constant. So even a platform doesn't support vec_duplicate, it could
still do clear by pieces if it supports const0 move by that mode.
Compared to the
Am 14. August 2024 01:27:33 MESZ schrieb Alejandro Colomar :
> Hi Xavier,
>
> On Wed, Aug 14, 2024 at 12:38:53AM GMT, Xavier Del Campo Romero wrote:
> > I have been overseeing these last emails -
>
> Ahhh, good to know; thanks! :)
>
> > thank you very much for your
> > efforts, Alex!
>
> :-)
>
> -Original Message-
> From: Andrew Pinski (QUIC)
> Sent: Monday, June 10, 2024 12:23 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Andrew Pinski (QUIC)
> Subject: [PATCH v2] aarch64: Improve popcount for bytes
> [PR113042]
>
> For popcount for bytes, we don't need the reduction addition
> afte
On Wed, Aug 14, 2024 at 3:28 AM liuhongt wrote:
>
> It results in 2 failures for x86_64-pc-linux-gnu{\
> -march=cascadelake};
>
> gcc: gcc.target/i386/extendditi3-1.c scan-assembler cqt?o
> gcc: gcc.target/i386/pr113560.c scan-assembler-times \tmulq 1
>
> For pr113560.c, now GCC generates mulx ins
On Wed, Aug 14, 2024 at 3:28 AM liuhongt wrote:
>
> It results in 2 failures for x86_64-pc-linux-gnu{\
> -march=cascadelake};
>
> gcc: gcc.target/i386/extendditi3-1.c scan-assembler cqt?o
> gcc: gcc.target/i386/pr113560.c scan-assembler-times \tmulq 1
>
> For pr113560.c, now GCC generates mulx ins
Hi,
I submitted a patch to change the mode checking for
CLEAR_BY_PIECES.
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660344.html
It causes some regressions on aarch64. With the patch,
V2x8QImode is used to do clear by pieces instead of TImode as
vector mode is preferable and V2x8QImo
101 - 121 of 121 matches
Mail list logo
