This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Tighten checking for 'X' constraints
- From: Jakub Jelinek <jakub at redhat dot com>
- To: gcc-patches at gcc dot gnu dot org, Robert Suchanek <Robert dot Suchanek at imgtec dot com>, rsandifo at linux dot vnet dot ibm dot com, Jeff Law <law at redhat dot com>, Eric Botcazou <ebotcazou at adacore dot com>
- Date: Wed, 16 Apr 2014 15:37:17 +0200
- Subject: Re: RFA: Tighten checking for 'X' constraints
- Authentication-results: sourceware.org; auth=none
- References: <87sipejow3 dot fsf at talisman dot default> <20140416092114 dot GE1817 at tucnak dot redhat dot com> <87fvldpnb3 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <20140416121407 dot GG1817 at tucnak dot redhat dot com> <87tx9to1ah dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Apr 16, 2014 at 02:24:06PM +0100, Richard Sandiford wrote:
> > side-effect of inline-asm on certain location in memory, but don't really
> > need the address of that memory. Often "memory" is too big hammer,
> > people often say that certain inline-asm uses or sets or uses/sets or
> > clobbers say 100 byte long piece of memory somewhere, but the operand is
> > there solely to tell the compiler what memory it is.
> > I think "X" constraint is good for that if you aren't planning to actually
> > use the address anywhere. E.g. you call in inline-asm some function,
> > but the address construction is in the callee, there is no point to costly
> > compute the address in the caller (say for -fPIC).
>
> If we want to replace the address with a scratch, I think we should do
> it at expand time so that all unneeded dependent code gets removed,
> rather than doing it only if the address isn't valid after optimisation.
> But since there's not AFAIK ever been a rule that "X" operands can't be
> printed, I think we should only do that if the operand isn't mentioned
> in the asm string.
>
> So would that be OK as a compromise? At expand time, check which
> operands are used (via get_referenced_operands). If an operand isn't
> used, is a MEM, has a constraint string that is exactly "X", and is
> not tied to other operands via matching constraints, replace the MEM
> address with (scratch). Then allow (mem (scratch)) as well as
> CONSTANT_P and general_operand in check_asm_operands?
>
> I suppose a follow-on optimisation would be to convert "m" into "X"
> in the same situation.
Creating a (mem (scratch)) too early may pessimize code too much,
perhaps it can be used during say sched1 etc. for alias analysis, (mem
(scratch)) is considered to alias everything,.
Plus, I think at least so far we have not been doing different decisions
based on whether some operand has been referenced in the template or not,
not sure if it is desirable to introduce it.
Anyway, others can have different opinion on what "X" should mean,
CCing Jeff and Eric.
Jakub