On Thu, 31 Aug 2023, 17:05 Alejandro Colomar via Gcc,
wrote:
> Hi!
>
> I've been confused for some time with a compilation error that
> pointed to a slightly-off location. I wasn't seeing that I used
> a temporary variable in a constant expression. The code could be
> reduced to:
>
> $ cat cons
(Looks like this was committed as r14-3580-g597b9ec69bca8a)
> Cc: gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org, Eric Feng
> From: Eric Feng via Gcc
> gcc/testsuite/ChangeLog:
> PR analyzer/107646
> * gcc.dg/plugin/analyzer_cpython_plugin.c: Implements reference count
> * checking for PyOb
On Thu, Aug 31, 2023 at 4:19 PM David Malcolm wrote:
>
> On Thu, 2023-08-31 at 15:09 -0400, Eric Feng wrote:
> > On Thu, Aug 31, 2023 at 1:01 PM David Malcolm
> > wrote:
> > >
> > > On Wed, 2023-08-30 at 18:15 -0400, Eric Feng wrote:
>
> [...]
>
> > > >
> > > > Thanks; pushed to trunk with nits f
Snapshot gcc-11-20230831 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20230831/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On Thu, 2023-08-31 at 15:09 -0400, Eric Feng wrote:
> On Thu, Aug 31, 2023 at 1:01 PM David Malcolm
> wrote:
> >
> > On Wed, 2023-08-30 at 18:15 -0400, Eric Feng wrote:
[...]
> > >
> > > Thanks; pushed to trunk with nits fixed:
> > > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=597b9ec69bca8a
On Thu, Aug 31, 2023 at 1:01 PM David Malcolm wrote:
>
> On Wed, 2023-08-30 at 18:15 -0400, Eric Feng wrote:
> > On Tue, Aug 29, 2023 at 5:14 PM David Malcolm
> > wrote:
> > >
> > > On Tue, 2023-08-29 at 13:28 -0400, Eric Feng wrote:
> > > > Additionally, by using the old model and the pointer pe
On Wed, 2023-08-30 at 18:15 -0400, Eric Feng wrote:
> On Tue, Aug 29, 2023 at 5:14 PM David Malcolm
> wrote:
> >
> > On Tue, 2023-08-29 at 13:28 -0400, Eric Feng wrote:
> > > Additionally, by using the old model and the pointer per your
> > > suggestion,
> > > we are able to find the representati
Hi!
I've been confused for some time with a compilation error that
pointed to a slightly-off location. I wasn't seeing that I used
a temporary variable in a constant expression. The code could be
reduced to:
$ cat const.c
int
main(void)
{
int x = 42;
_Static_assert(0 || 7 > x,
My translation validation tool reports some miscompilations related to the
internal call CLZ(0) when CLZ_DEFINED_VALUE_AT_ZERO is false, but I am not
sure I use the correct semantics...
I started by modeling CLZ(0) as undefined behavior, but that made the tool
report a miscompilation for gcc.c
On Thu, 31 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi.
>
> /* Keep track of the VF for each mode. Initialize all to 0 which indicates
> a mode has not been analyzed. */
> auto_vec cached_vf_per_mode;
> for (unsigned i = 0; i < vector_modes.length (); ++i)
> cached_vf_per_m
Hi, Richi.
/* Keep track of the VF for each mode. Initialize all to 0 which indicates
a mode has not been analyzed. */
auto_vec cached_vf_per_mode;
for (unsigned i = 0; i < vector_modes.length (); ++i)
cached_vf_per_mode.safe_push (0);
I saw codes here:
the 'cached_vf_per_mode' i
Hi, Richi.
>> I don't think that's "good" use of the API.
You mean I should use 'better_main_loop_than_p‘ ？
Yes. I plan to use it.
Thanks.
juzhe.zh...@rivai.ai
From: Richard Biener
Date: 2023-08-31 19:29
To: juzhe.zh...@rivai.ai
CC: gcc; richard.sandiford
Subject: Re: Re: Question about dynam
On Thu, 31 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Hi. Thanks Richard and Richi.
>
> Now, I figure out how to choose smaller LMUL now.
>
> void
> costs::finish_cost (const vector_costs *scalar_costs)
> {
> loop_vec_info loop_vinfo = dyn_cast (m_vinfo);
> if (loop_vinfo)
> {
> if (l
Hi. Thanks Richard and Richi.
Now, I figure out how to choose smaller LMUL now.
void
costs::finish_cost (const vector_costs *scalar_costs)
{
loop_vec_info loop_vinfo = dyn_cast (m_vinfo);
if (loop_vinfo)
{
if (loop_vinfo->vector_mode == RVVM8SImode
|| riscv_v_ext_vls_mode_p (l
On Thu, 31 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Thanks Richi.
>
> I am trying to figure out how to adjust finish_cost to lower the LMUL
>
> For example:
>
> void
> foo (int32_t *__restrict a, int32_t *__restrict b, int n)
> {
> for (int i = 0; i < n; i++)
> a[i] = a[i] + b[i];
> }
>
>
Hi David,
On Wed, Aug 30, 2023 at 1:01 AM David Malcolm wrote:
>
> > ?
>
> Yes; please submit it, so that we can work towards getting what you
> have into trunk.
>
> Given that we don't properly support C++ yet, improvements to C++
> support don't have to be perfect.
>
>
It is next in queue for
"juzhe.zh...@rivai.ai" writes:
> Thanks Richi.
>
> I am trying to figure out how to adjust finish_cost to lower the LMUL
>
> For example:
>
> void
> foo (int32_t *__restrict a, int32_t *__restrict b, int n)
> {
> for (int i = 0; i < n; i++)
> a[i] = a[i] + b[i];
> }
>
> preferred_simd_mode p
Thanks Richi.
I am trying to figure out how to adjust finish_cost to lower the LMUL
For example:
void
foo (int32_t *__restrict a, int32_t *__restrict b, int n)
{
for (int i = 0; i < n; i++)
a[i] = a[i] + b[i];
}
preferred_simd_mode pick LMUL = 8 (RVVM8SImode)
Is is possible that we can a
On Thu, 31 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richard and Richi.
>
> Currently, we are statically returning vectorization factor in
> 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE'
> according to compile option.
>
> For example:
> void
> foo (int32_t *__restrict a, int32_t *__restrict b, int n
19 matches
Mail list logo
