This is the mail archive of the 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: RFA: Tighten checking for 'X' constraints

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.


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