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]

Re: PATCH: PA PIC symbolic memory fix PART 1




  In message <200102201557.KAA04868@hiauly1.hia.nrc.ca>you write:
  > Having thought a bit more about this, I believe that I can better explain
  > why IS_RELOADING_PSEUDO_P isn't needed and is in fact dangerous.
  > 
  > The problem that the patch was intended to fix was the substitution of
  > MEMs from other insns into the standard movsi/movdi pattern.  It was
  > noticed first with the LO_SUM PIC reference but I believe it also affects
  > the PLUS pic reference MEM, and possibly other MEM insns in the machine
  > definition.
The only way it can affect other MEM insns is if we have set up an
equivalence. 

Looking at pa.md, I do see that we still have the -fpic pattern to do 
short loads out of the DLT (how I missed this 15 minutes ago is beyond
me).  Part of me is telling me to just zap small PIC support for the
PA.  The reality is it's never used and just complicates the port.

The rest of the special memory reference patterns are not going to be
setting up equivalences, which in turn means they're not going to be
subject to the substitutions reload does when it sets up equivalences.

[ Long term I really would like to move those into the standard patterns
  too, but we need a fair amount of infrastructure work to make that 
  happen. ]

  > The Q constraint as it stands accepts DLT memory references because
  > the forms used are not checked in symbolic_memory_operand.  In order
  > to stop the substitution of DLT references, symbolic memory_operand_operand
  > needs to be revised to detect these references.  When this is done, reload
  > will generate a spill for a DLT reference rather than just substituting
  > it directly into a pattern which couldn't handle it.
Is the point of this to stop the substitution when we have equivalent forms?
If so, then I think we're still barking up the wrong tree.

jeff


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