Committed, thanks Jeff.
Pan
-Original Message-
From: Jeff Law
Sent: Saturday, May 20, 2023 12:24 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang, Yanzhang
Subject: Re: [PATCH] Mode-Switching: Fix local array maybe uninitialized warning
Lgtm
於 2023年5月17日 週三，16:14寫道：
> From: Pan Li
>
> This patch support the RVV VREINTERPRET from the int to the
> vbool[2|4|8|16|32|64]_t. Aka:
>
> vbool[2|4|8|16|32|64]_t __riscv_vreinterpret_x_x(v{u}int[8|16|32|64]_t);
>
> These APIs help the users to convert vector LMUL=1 integer to
> vbool[2-6
This is a case which I noticed while working on the previous patch.
Sometimes we end up with `a == CST` instead of comparing against 0.
This happens in the following code:
```
unsigned f(unsigned t)
{
if (t & ~(1<<30)) __builtin_unreachable();
t ^= (1<<30);
return t != 0;
}
```
We should han
While working something else, I noticed we could improve
the following function code generation:
```
unsigned f(unsigned t)
{
if (t & ~(1<<30)) __builtin_unreachable();
return t != 0;
}
```
Right know we just emit a comparison against 0 instead
of just a shift right by 30.
There is code in do_s
Hi!
On the following testcase we hang, because POLY_INT_CST is CONSTANT_CLASS_P,
but BIT_AND_EXPR with it and INTEGER_CST doesn't simplify and the
(x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2)
simplification actually relies on the (CST1 & CST2) simplification,
otherwise it is a deoptimization, t
install.texi has become a bit blown up over the years, with good potential
to trim chaff and simplify things for our users.
This is just one step of possibly many more.
Pushed.
Gerald
gcc/ChangeLog:
* doc/install.texi (Specific): Remove de facto empty alpha*-*-*
section.
---
The problem is I used expand_expr with the target but
we don't want to use the target here as it is the wrong
mode for the original expression. The testcase would ICE
deap down while trying to do a move to use the target.
Anyways just calling expand_expr with NULL_EXPR fixes
the issue.
Committed a
On 5/20/23 19:09, Andrew Pinski via Gcc-patches wrote:
The problem is I used expand_expr with the target but
we don't want to use the target here as it is the wrong
mode for the original expression. The testcase would ICE
deap down while trying to do a move to use the target.
Anyways just call
On Sat, May 20, 2023 at 6:26 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 5/20/23 19:09, Andrew Pinski via Gcc-patches wrote:
> > The problem is I used expand_expr with the target but
> > we don't want to use the target here as it is the wrong
> > mode for the original expression. The testcase wo
On 5/20/23 21:05, Andrew Pinski wrote:
On Sat, May 20, 2023 at 6:26 PM Jeff Law via Gcc-patches
wrote:
On 5/20/23 19:09, Andrew Pinski via Gcc-patches wrote:
The problem is I used expand_expr with the target but
we don't want to use the target here as it is the wrong
mode for the origina
On Sat, May 20, 2023 at 8:25 PM Jeff Law wrote:
>
>
>
> On 5/20/23 21:05, Andrew Pinski wrote:
> > On Sat, May 20, 2023 at 6:26 PM Jeff Law via Gcc-patches
> > wrote:
> >>
> >>
> >>
> >> On 5/20/23 19:09, Andrew Pinski via Gcc-patches wrote:
> >>> The problem is I used expand_expr with the target
Committed, thanks Kito.
Pan
From: Kito Cheng
Sent: Saturday, May 20, 2023 9:58 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; Wang, Yanzhang
Subject: Re: [PATCH] RISC-V: Support RVV VREINTERPRET from v{u}int*_t to
vbool[2-64]_t
Lgtm
mailto:pan2...@intel.com>>於 2023年5月17
On Sat, May 20, 2023 at 8:28 PM Andrew Pinski wrote:
>
> On Sat, May 20, 2023 at 8:25 PM Jeff Law wrote:
> >
> >
> >
> > On 5/20/23 21:05, Andrew Pinski wrote:
> > > On Sat, May 20, 2023 at 6:26 PM Jeff Law via Gcc-patches
> > > wrote:
> > >>
> > >>
> > >>
> > >> On 5/20/23 19:09, Andrew Pinski
On Sat, May 20, 2023 at 8:32 PM Andrew Pinski wrote:
>
> On Sat, May 20, 2023 at 8:28 PM Andrew Pinski wrote:
> >
> > On Sat, May 20, 2023 at 8:25 PM Jeff Law wrote:
> > >
> > >
> > >
> > > On 5/20/23 21:05, Andrew Pinski wrote:
> > > > On Sat, May 20, 2023 at 6:26 PM Jeff Law via Gcc-patches
>
On 5/20/23 21:28, Andrew Pinski wrote:
On Sat, May 20, 2023 at 8:25 PM Jeff Law wrote:
On 5/20/23 21:05, Andrew Pinski wrote:
On Sat, May 20, 2023 at 6:26 PM Jeff Law via Gcc-patches
wrote:
On 5/20/23 19:09, Andrew Pinski via Gcc-patches wrote:
The problem is I used expand_expr wit
I had thought extract_bit_field bitpos argument was the shifted position
and not the bitposition like BIT_FIELD_REF so I had removed the code which
would use the correct bitposition for BYTES_BIG_ENDIAN.
Committed as obvious; I checked big-endian MIPS to make sure we are now
producing the correct
I had thought extract_bit_field bitpos argument was the shifted position
and not the bitposition like BIT_FIELD_REF so I had removed the code which
would use the correct bitposition for BYTES_BIG_ENDIAN.
Committed as obvious; I checked big-endian MIPS to make sure we are now
producing the correct
> Am 20.05.2023 um 22:33 schrieb Jakub Jelinek :
>
> Hi!
>
> On the following testcase we hang, because POLY_INT_CST is CONSTANT_CLASS_P,
> but BIT_AND_EXPR with it and INTEGER_CST doesn't simplify and the
> (x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2)
> simplification actually relies on t
18 matches
Mail list logo
