Re: [PATCH] gimplify: Don't optimize register const vars to static [PR93949]
Am Samstag, den 29.02.2020, 10:57 +0100 schrieb Jakub Jelinek: > On Sat, Feb 29, 2020 at 09:50:00AM +, Uecker, Martin wrote: > > One could also simply remove the error in varasm.c. This > > would preserve the optimization. As a side effect, this > > would allow register without __asm__ at file scope, but > > there do not seem to be any disadvantages. (register > > at file scope is already diagnosed by the C FE when > > using --pedantic). > > First of all, such a change wouldn't be appropriate for backports, Ok. > and IMHO > makes only sense if we actually start optimizing based on that (assuming > the address of the var can't be taken in alias analysis etc.). FYI: There is a proposal for C2X from a developer of compiler for small embedded systems to allow this for optimization. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2486.htm Best, Martin
Re: [PATCH] gimplify: Don't optimize register const vars to static [PR93949]
On Sat, Feb 29, 2020 at 09:50:00AM +, Uecker, Martin wrote: > One could also simply remove the error in varasm.c. This > would preserve the optimization. As a side effect, this > would allow register without __asm__ at file scope, but > there do not seem to be any disadvantages. (register > at file scope is already diagnosed by the C FE when > using --pedantic). First of all, such a change wouldn't be appropriate for backports, and IMHO makes only sense if we actually start optimizing based on that (assuming the address of the var can't be taken in alias analysis etc.). Jakub
Re: [PATCH] gimplify: Don't optimize register const vars to static [PR93949]
One could also simply remove the error in varasm.c. This
would preserve the optimization. As a side effect, this
would allow register without __asm__ at file scope, but
there do not seem to be any disadvantages. (register
at file scope is already diagnosed by the C FE when
using --pedantic).
Best,
Martin
Am Donnerstag, den 27.02.2020, 10:31 +0100 schrieb Richard Biener:
> On Thu, 27 Feb 2020, Jakub Jelinek wrote:
>
> > Hi!
> >
> > The following testcase is rejected, while it was accepted in 3.4 and earlier
> > (before tree-ssa merge).
> > The problem is that we decide to promote the const variable to TREE_STATIC,
> > but TREE_STATIC DECL_REGISTER VAR_DECLs may only be the global register vars
> > and so assemble_variable/make_decl_rtl diagnoses it.
> >
> > Either we do what the following patch does, where we could consider
> > register as a hint the user doesn't want such optimization, because if
> > something is forced static, it is not "register" anymore and register static
> > is not valid in C either, or we could clear DECL_REGISTER instead, but would
> > still need to punt at least on DECL_HARD_REGISTER cases.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> OK.
>
> Thanks,
> Richard.
>
> > 2020-02-27 Jakub Jelinek
> >
> > PR c/93949
> > * gimplify.c (gimplify_init_constructor): Don't promote readonly
> > DECL_REGISTER variables to TREE_STATIC.
> >
> > * gcc.c-torture/compile/pr93949.c: New test.
> >
> > --- gcc/gimplify.c.jj 2020-02-25 13:54:02.087091120 +0100
> > +++ gcc/gimplify.c 2020-02-26 19:30:57.466490166 +0100
> > @@ -4923,6 +4923,7 @@ gimplify_init_constructor (tree *expr_p,
> > && num_nonzero_elements > 1
> > && TREE_READONLY (object)
> > && VAR_P (object)
> > + && !DECL_REGISTER (object)
> > && (flag_merge_constants >= 2 || !TREE_ADDRESSABLE (object))
> > /* For ctors that have many repeated nonzero elements
> > represented through RANGE_EXPRs, prefer initializing
> > --- gcc/testsuite/gcc.c-torture/compile/pr93949.c.jj2020-02-26
> > 19:42:15.754530691 +0100
> > +++ gcc/testsuite/gcc.c-torture/compile/pr93949.c 2020-02-26
> > 19:42:08.153642329 +0100
> > @@ -0,0 +1,7 @@
> > +/* PR c/93949 */
> > +
> > +void
> > +foo (void)
> > +{
> > + register const double d[3] = { 0., 1., 2. };
> > +}
> >
> > Jakub
> >
> >
>
>
Re: [PATCH] gimplify: Don't optimize register const vars to static [PR93949]
On Thu, 27 Feb 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is rejected, while it was accepted in 3.4 and earlier
> (before tree-ssa merge).
> The problem is that we decide to promote the const variable to TREE_STATIC,
> but TREE_STATIC DECL_REGISTER VAR_DECLs may only be the global register vars
> and so assemble_variable/make_decl_rtl diagnoses it.
>
> Either we do what the following patch does, where we could consider
> register as a hint the user doesn't want such optimization, because if
> something is forced static, it is not "register" anymore and register static
> is not valid in C either, or we could clear DECL_REGISTER instead, but would
> still need to punt at least on DECL_HARD_REGISTER cases.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Thanks,
Richard.
> 2020-02-27 Jakub Jelinek
>
> PR c/93949
> * gimplify.c (gimplify_init_constructor): Don't promote readonly
> DECL_REGISTER variables to TREE_STATIC.
>
> * gcc.c-torture/compile/pr93949.c: New test.
>
> --- gcc/gimplify.c.jj 2020-02-25 13:54:02.087091120 +0100
> +++ gcc/gimplify.c2020-02-26 19:30:57.466490166 +0100
> @@ -4923,6 +4923,7 @@ gimplify_init_constructor (tree *expr_p,
> && num_nonzero_elements > 1
> && TREE_READONLY (object)
> && VAR_P (object)
> + && !DECL_REGISTER (object)
> && (flag_merge_constants >= 2 || !TREE_ADDRESSABLE (object))
> /* For ctors that have many repeated nonzero elements
> represented through RANGE_EXPRs, prefer initializing
> --- gcc/testsuite/gcc.c-torture/compile/pr93949.c.jj 2020-02-26
> 19:42:15.754530691 +0100
> +++ gcc/testsuite/gcc.c-torture/compile/pr93949.c 2020-02-26
> 19:42:08.153642329 +0100
> @@ -0,0 +1,7 @@
> +/* PR c/93949 */
> +
> +void
> +foo (void)
> +{
> + register const double d[3] = { 0., 1., 2. };
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
