This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: prevent REG_EQUAL on set-mem insns
- From: Olivier Hainque <hainque at adacore dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org, hainque at adacore dot com, richard dot guenther at gmail dot com
- Date: Fri, 1 Oct 2010 18:35:38 +0200
- Subject: Re: prevent REG_EQUAL on set-mem insns
- References: <20100910162614.GA4442@cardhu.act-europe.fr> <AANLkTinBSU2Xe13K9++BqFFOxk59QbCkPQd5HsfFUMA9@mail.gmail.com> <20100912165804.GA4661@cardhu.act-europe.fr>
Hello,
Back on this topic after a few experiments.
Steven wrote:
> I think it would be a good idea to add some code to
> set_unique_reg_note for good measure.
The patch below bootstraps and passes regression tests fine for
mainline on both x86_64-linux and ppc-aix. I'm unclear on the
importance of the potential effects.
Thinking about it, maybe REG_P alone is too restrictive: seems like
SUBREG of REG_P would be ok as well, no ?
* emit-rtl.c (set_unique_reg_note): Don't add REG_EQUAL or REG_EQUIV
on a SET if the destination isn't a REG.
Thanks for your feedback,
Olivier
Index: emit-rtl.c
===================================================================
--- emit-rtl.c (revision 164744)
+++ emit-rtl.c (working copy)
@@ -5143,6 +5143,18 @@
if (GET_CODE (datum) == ASM_OPERANDS)
return NULL_RTX;
+ /* Don't add REG_EQUAL/REG_EQUIV notes on a single_set destination which
+ isn't a REG. Such notes are invalid, could lead to bogus assumptions
+ downstream (e.g. that a (set MEM) couldn't trap), and many callers
+ just don't care checking. Note that we might have single_set (insn)
+ == 0 here, typically from reload attaching REG_EQUAL to USEs for
+ inheritance purposes. */
+ {
+ rtx set = single_set (insn);
+ if (set && ! REG_P (SET_DEST (set)))
+ return NULL_RTX;
+ }
+
if (note)
{
XEXP (note, 0) = datum;