Unshare constants in the constant pool (PR target/42894)

Hi!

As discussed in the PR, if a non-shareable constant is force_const_mem
and the original expression is used elsewhere in the IL (e.g. in REG_EQUAL
or REG_EQUIV note), unshare_all_rtl doesn't unshare it, but modification of
the IL might result in changes of the constant in theory and if
avoid_constant_pool_reference result is then pushed somewhere else into the
IL, we get RTL sharing errors (as on arm on this testcase).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok if it passes
bootstrap/regtest also on arm?

2011-01-26  Jakub Jelinek  <jakub@redhat.com>

	PR target/42894
	* varasm.c (force_const_mem): Store copy of x in desc->constant
	instead of x itself.

	* gcc.dg/tls/pr42894.c: New test.


	Jakub

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/26/11 12:37, Jakub Jelinek wrote:
> Hi!
> 
> As discussed in the PR, if a non-shareable constant is force_const_mem
> and the original expression is used elsewhere in the IL (e.g. in REG_EQUAL
> or REG_EQUIV note), unshare_all_rtl doesn't unshare it, but modification of
> the IL might result in changes of the constant in theory and if
> avoid_constant_pool_reference result is then pushed somewhere else into the
> IL, we get RTL sharing errors (as on arm on this testcase).
Well, one could easily argue that using the original expression in the
REG_EQUAL note is incorrect as well.  In fact, looking over all the
calls to set_unique_reg_note shows that most either copy the value or
generate a new one.

I think that means we actually want both the varasm.c and the expr.c
change to avoid incorrect sharing.

jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNQMp1AAoJEBRtltQi2kC7LW4H/2MsJOnqPuZx+vKT5+4DCBYT
dwq6/4buU/Vbr3JOMHxNg+9FFKpC3s2gwl9N1JcsFPvBZw5XOgTuLZXR2KHoL4ub
xhF4Of1UaDIPsVZvxJnCA905ArHbIxKVELHgitWcvyIkGcJXV9u2/XXWBy27H5Ie
QvSc0ojBmEulqPnzI4r2UBlAFgKyix3OPEiZP/k8LEXAidVsezl4tB1T+kba6NtY
26Aq6mLiJ8kNQJIUjlv1I8a/pt9dMTP+Begvclro7x178caPIts+qhbucwNSHCf8
6jZbt6tm5JWUz87tzLtzC1/4rGvMuJXdpyvYUc7ul3LCe9KUNHGGxTbF359jRus=
=Vzz3
-----END PGP SIGNATURE-----

On Wed, Jan 26, 2011 at 06:29:25PM -0700, Jeff Law wrote:
> > As discussed in the PR, if a non-shareable constant is force_const_mem
> > and the original expression is used elsewhere in the IL (e.g. in REG_EQUAL
> > or REG_EQUIV note), unshare_all_rtl doesn't unshare it, but modification of
> > the IL might result in changes of the constant in theory and if
> > avoid_constant_pool_reference result is then pushed somewhere else into the
> > IL, we get RTL sharing errors (as on arm on this testcase).
> Well, one could easily argue that using the original expression in the
> REG_EQUAL note is incorrect as well.  In fact, looking over all the
> calls to set_unique_reg_note shows that most either copy the value or
> generate a new one.
> 
> I think that means we actually want both the varasm.c and the expr.c
> change to avoid incorrect sharing.

I think the reason why most of the set_unique_reg_note calls copy_rtx
is that the pattern is usually kept in the insn (or in some other insn).
In the emit_move_insn case it specifically tests that the pattern is not
there (well, some weird target could embed it in some unspec or something),
the reason I changed force_const_mem was to deal with any other uses of
force_const_mem.

But I guess if you strongly prefer to have it in both places I can test a
patch.

	Jakub