This is the mail archive of the
mailing list for the GCC project.
Re: PR rtl-optimization/15248 -- semi-latent reload bug
- From: Jeffrey A Law <law at redhat dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 03 May 2005 14:08:45 -0600
- Subject: Re: PR rtl-optimization/15248 -- semi-latent reload bug
- References: <Pine.LNX.firstname.lastname@example.org>
- Reply-to: law at redhat dot com
On Thu, 2005-04-21 at 15:02 -0600, Roger Sayle wrote:
> Thanks for the explanations. Clearly my understanding is along the
> right tracks.
> In this case, wouldn't a better solution be to allow the equivalencing
> of the pseudo to the read-only memory, but instead simply not to emit
> the store that attempts to write to read-only memory.
Again, in theory, yes. But certain aspects of RTL and our reload
implementation make this significantly more difficult.
> We know that the
> location already contains the correct value, so somewhere in reload,
> where ever we spill this pseudo, we just need a check something like:
> !(MEM_P(x) && !MEM_READONLY_P(x)) probably before calling emit_insn.
That would only be sufficient for eliminating new insns which store
the value, such as a reload-out. It is not sufficient for handling...
> I appreciate your comment that the implementation might be slightly
> more involved in order to deal with PARALLELs, CLOBBERs and the like,
> but I'd be interested in knowing where the erroneous code is.
If you have one of these stores inside a parallel, then you're going
to have to search the entire IL for them, then somehow modify the
insn into something that is recognizable, but without the offending
store. I don't know a reliable way to do that.