On Thu, Jul 2, 2020 at 9:08 PM Eric Botcazou wrote:
>
> > So this variant combined with the rest of the patch is OK then.
>
> Thanks. It occurred to me that using string_constant might be slightly better
> (iti is already used by gimple_fold_builtin_memchr in the same file).
OK.
Thanks,
> So this variant combined with the rest of the patch is OK then.
Thanks. It occurred to me that using string_constant might be slightly better
(iti is already used by gimple_fold_builtin_memchr in the same file).
* gimple-fold.c (gimple_fold_builtin_memory_op): Fold calls that were
On Thu, Jul 2, 2020 at 12:27 PM Eric Botcazou wrote:
>
> > Sorry for the ping-pong but why's using a new char[len] type problematic?
>
> Because the type may be incompatible with that of the STRING_CST, so we would
> need to build a new STRING_CST with the new type.
I see.
> > That said, I do
> Sorry for the ping-pong but why's using a new char[len] type problematic?
Because the type may be incompatible with that of the STRING_CST, so we would
need to build a new STRING_CST with the new type.
> That said, I do like p2 more even if we need to special-case STRING_CST
> sources at the
> Hmm, that's a good question - so would your patch be replaceable by
> simply amending var_decl_component_p by
>
> (var_decl_component_p (TREE_OPERAND (src, 0))
>
>|| TREE_CODE (TREE_OPERAND (src, 0)) == STRING_CST)
>
> ?
The gimple_call_alloca_for_var_p (stmt) kludge is still needed
On Wed, Jul 1, 2020 at 12:32 PM Eric Botcazou wrote:
>
> > + && TREE_CODE (TREE_OPERAND (src, 0)) == STRING_CST
> > + && tree_int_cst_equal
> > +(TYPE_SIZE_UNIT (TREE_TYPE (TREE_OPERAND (src, 0))), len))
> > + {
> >
> > I guess we miss a BITS_PER_UNIT == 8 check
> + && TREE_CODE (TREE_OPERAND (src, 0)) == STRING_CST
> + && tree_int_cst_equal
> +(TYPE_SIZE_UNIT (TREE_TYPE (TREE_OPERAND (src, 0))), len))
> + {
>
> I guess we miss a BITS_PER_UNIT == 8 check here?
OK, added.
> + gimple_set_vuse (new_stmt,
On Wed, Jul 1, 2020 at 8:50 AM Eric Botcazou wrote:
>
> Hi,
>
> the GIMPLE store merging pass doesn't merge STRING_CSTs in the general case,
> although they are accepted by native_encode_expr; the reason is that the pass
> only works with integral modes, i.e. with chunks whose size is a power of
Hi,
the GIMPLE store merging pass doesn't merge STRING_CSTs in the general case,
although they are accepted by native_encode_expr; the reason is that the pass
only works with integral modes, i.e. with chunks whose size is a power of two.
There are two possible ways of extending it to handle
