> 2011-03-22 Andreas Krebbel
>
> * recog.c (canonicalize_change_group): Use validate_unshare_change.
OK, thanks.
--
Eric Botcazou
Hi,
this is an alternate solution to the problem described in:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00187.html
Although I still prefer the patch above since it would make
validate_change easier to use I understand that it might add
unnecessary unsharing. The unsharing for subsequent chang
> I think with the patch validate_(unshare)_change becomes easier to use. You
> can still decide locally if you want unsharing or not. Without taking into
> account in which contexts your function gets called. I consider this a big
> advantage.
You're supposed to know what you're doing though and
On 03/18/2011 09:11 PM, Eric Botcazou wrote:
>> The attached patch prevents that by doing RTX unsharing for all
>> subsequent changes after finding a single change where unsharing has
>> been explicitly requested.
>
> This looks like a big hammer. Why not doing it in canonicalize_change_group,
>
> The attached patch prevents that by doing RTX unsharing for all
> subsequent changes after finding a single change where unsharing has
> been explicitly requested.
This looks like a big hammer. Why not doing it in canonicalize_change_group,
i.e. calling validate_unshare_change instead of valid
Hi,
we currently miss to do RTX unsharing in some cases when mixing
validate_change requests with and without rtx unsharing in the same
change group.
Debugging a setjmp testcase on s390 I've seen the following behaviour:
In an insn like A = B + C B is replaced with D in fold_rtx. Unsharing is
re
