Re: subreg rtl documentation

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Jim Wilson wrote:
> Richard Sandiford wrote:
> > I don't want to make a fuss, but for the record, as someone involved in
> > writing these changes, I feel very uncomfortable seeing a patch like
> > this being applied without a maintainer approving it.
>
> I'll approve it after the fact, just to make it tidy.
>
> I'm curious why the language about subregs of mems was removed.  We 
> still have code that can create them.  Search for INSN_SCHEDULING in 
> combine.c and recog.c.  This is a bit of a historical artifact. 
> Originally, we allowed subregs of mem knowing that reload would fix 
> them.  When RISC and instruction scheduling support was added, this 
> stuff was disabled to that we could schedule the explicit memory 
> reference that reload would otherwise implicitly generate, but this 
> was only done for targets that have insn scheduling support.  17 years 
> or so later the INSN_SCHEDULING checks are still there, which means we 
> can still generate subregs of mems for targets that don't enable insn 
> scheduling.  Granted, there aren't many targets that don't enable 
> scheduling nowadays, but it would still be nice if this was fixed.
>
> The docs say that the upper bits of paradoxical subregs are always 
> undefined.  This is not true for paradoxical subregs of mems when 
> LOAD_EXTEND_OP is defined.  See the use in combine.  Of course, this 
> assumes that we still have subregs of mems.
>
> Another possible issue here are the subregs generated by PROMOTE_MODE. 
> These are a bit different that the subregs you describe here.  These 
> are always paradoxical, and they always have well defined upper bits, 
> either sign-extended or zero-extended, or on 32-bit itanium 
> ptr-extended.  See the SUBREG_PROMOTED_* docs and uses.
>
> Jim
Jim,

Thanks,   I of course should have invited you from the beginning on this 
issue. 

I think that the big picture thinking was that richard and i had not 
only vetted the text with the community, but that unlike the many things 
that get vetted on the mailing list, this one did not turn into a flame 
war, so it was easy to put together a document that reflected the 
feelings of those that contributed.   Given that at least two of the 
people that participated in that were gwm's who were instrumental in 
developing the parts of the compiler that used subregs, i think that 
david felt that it had been vetted enough and that this was not just a 
rouge change to the documents to reflect one person's perspective.   

The issue with the mem subregs did not come up in the previous 
discussions and as you point out does seem to have been dropped by us.   
Going back and reading the text that was dropped and what you say here, 
gives me the feeling that there is yet another complex use of subregs 
that was underdocumented in the original text that is certainly 
deserving of some enhancement.  
Unlike the area of subregs of hardregs, where the consensus opinion was 
that these should go away, there was just not much said about subregs of 
mems and it looks like the issue fell between the cracks.  

lets let the subregs of mem issue kick around for a few days and i will 
propose a patch based on what people say and the currently committed 
code that supports subregs of mem.  

Kenny