This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR rtl-optimization/15248 -- semi-latent reload bug

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]