This is the mail archive of the gcc@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: Illegitimate address in REG_EQUAL note: legal?


> Hello,
> 
> another problem with the current 3.1 on s390: 
> 
> gcse constant-propagation can substitute a constant
> term for a register into a memory address, with the
> resulting address being illegitimate.  

I guess it is valid.  We don't require REG_EQUIV expressions to match the
target constraints, we want them to describe directly what is going on.
> 
> (Specifically, gcse has pulled a (const (unspec ...))
> construct used to specify a GOT offset larger than 4K
> out of the constant pool and placed it inline into
> the address.  This does not work.)
> 
> Now, try_replace_reg does notice that something 
> isn't OK, as validate_replace_src fails.  However,
> if that happens, the illegitimate address is still
> placed into a REG_EQUAL note which is attached to
> the insn.
> 
> Unfortunately, this note gets promoted to a REG_EQUIV
> note later on, and when reload sees this note, it will
> create a reg_equiv_address entry for the pseudo.

I guess this is the problem - the REG_EQUIV notes have different
meaning for pre-reload and for reload/postreload, so I guess
somewhere here we should kill REG_EQUIV notes with values invalid
for reload.
SImilarry I would guess we should kill REG_EQUALs somewhere on
the progress as well, as they are invalid and some passes
common for post/pre reload, like cfg_cleanup may get confused.

Honza

> However, while req_equiv_address addresses are presumed
> to be illegitimate, reload does assume they are so for
> a couple of special reasons (i.e. not strictly legitimate,
> CONST_INT offset out of range etc.)
> 
> In this particular case, the address doesn't fit into
> any of these categories, and so find_reloads_address
> doesn't handle it correctly.  This results in the
> address showing up un-reloaded in the rtx after reload,
> causing an ICE in cleanup_subreg_operands due to an
> unrecognized insn.
> 
> 
> I'm at a loss to decide which of the involved parties
> is at fault here.  Either:
> 
> - REG_EQUAL notes should never contain illegitimate
>   memory addresses.
> 
>   In this case gcse try_replace_reg needs to be fixed.
>   [ Why does it keep things it *knows* to be invalid
>   around anyway?  The comment says it's done so as
>   'to not lose information'.  Am I missing something
>   here? ]
> 
> - REG_EQUAL notes may contain illegitimate addresses,
>   but REG_EQUIV notes not.
> 
>   In this case local-alloc probably needs to add
>   checks to ensure it only promotes valid REG_EQUAL
>   notes to REG_EQUIV.
> 
> - Both REG_EQUIV and REG_EQUAL notes may contain
>   illegitimate addresses.
> 
>   Then reload need to either handle such addresses
>   correctly in find_reloads_address, or else check
>   the note in advance and ignore it if is isn't
>   legitimate.
> 
> Any suggestions?
> 
> Bye,
> Ulrich
> 
> -- 
>   Dr. Ulrich Weigand
>   weigand@informatik.uni-erlangen.de


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