This is the mail archive of the
mailing list for the GCC project.
Re: PR target/21299 (reload accepting invalid asm)
- From: Richard Sandiford <richard at codesourcery dot com>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 09 Aug 2006 14:12:28 +0100
- Subject: Re: PR target/21299 (reload accepting invalid asm)
- References: <20060808131508.GE3150@kam.mff.cuni.cz>
Jan Hubicka <email@example.com> writes:
> This patch does two changes - one is obvious to make reg_fits_class_p called
> for each specified class (this bring reload idea in sync with recog's and it
> also will match more often in cases the specified constraints don't unify to
> existing class).
Is it obvious that find_reloads() rather than constrain_operands()
should change though?
Your attitude seems to be that, if an alternative has several
register class constraints, the operand must be completely contained
in one of those classes. I agree that that makes sense (and I agree
that it's what constrain_operands() expects), but in that case,
as you imply...
> Sadly this is not enough to fix the patch - the reload now correctly
> recognize that insn needs reloads, but it still picks the first
> alternative and subunion into "A" class for push_reload so it is later
> is satisfied with the instruction again.
....what are we doing computing the subunion of individual classes?
In general, a register picked from the subunion might straddle two
of those individual classes.
The problem isn't just in find_reloads(). preprocess_constraints()
(and indeed the recog_op_alt data itself) assumes you can sum up an
alternative using one class, namely the subunion of the individual
I think we need to clarify what it means to have several register
classes in the same alternative. Which interpretation is right?
constrain_operands(), or find_reloads() and preprocess_constraints()?
The constrain_operands() approach is more immediately obvious,
and means that the semantics of user asms will not depend on the set
of union classes defined by the backend (which should remain an
internal implementation detail IMO -- I don't think it's something
the user should see). On the other hand, it's more natural for
reload to treat sum up each alternative with a single class.
Perhaps we should just stop using the subunion and pick the largest
individual class instead? I think that would solve the PR too.