This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH 04/25] SPECIAL_REGNO_P



> On Sep 13, 2018, at 10:58 AM, Andrew Stubbs <ams@codesourcery.com> wrote:
> 
> On 13/09/18 15:49, Paul Koning wrote:
>> It's ambiguous, because the last sentence of that paragraph says "addm3 is used if addptrm3 is not defined."
> 
> I didn't read that as ambiguous; I read it as addm3 is assumed to work fine when addptr is not defined.
> 
>> I don't know of any change in this area.  All I know is that pdp11 has adds that clobber CC and it doesn't define addptrm3, relying on that last sentence.  I've tried LRA and for the most part it compiles successfully, I suppose I should verify the generated code based on the point you raised.  If I really have to define addptr, I'm in trouble because  save/restore CC is not easy on pdp11.
> 
> The code was added because we had a number of testcases that failed at runtime without it.
> 
> Admittedly, that was in a GCC 7 code-base, and I can't reproduce the failure with one of those test cases now (with addptr deleted), but possibly that's just noise.

Possibly relevant is that pdp11 is a "type 2" CC setting target, one where the machine description doesn't mention CC until after reload.  So if reload (LRA) is generating adds, the CC effect of that is invisible anyway until later passes that deal with the resulting clobbers and elimination, or not, of compares.

If that's what this is all about, some documentation clarification would help.  Can someone confirm (or refute) my guess?

	paul



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