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: Question regarding constraint usage within inline asm


Hi!

On Mon, Feb 25, 2019 at 06:32:53PM +0000, Michael Matz wrote:
> On Thu, 21 Feb 2019, Segher Boessenkool wrote:
> > > That said, the "bug" in the case we're seeing, is that asmcons rewrote 
> > > all of "input"'s pseudos, and it should be more careful to not create 
> > > rtl with illegal constraint usage that LRA cannot fix up.  With the 
> > > fix, operand %1 in the inline asm is no longer hard coded to r3 and it 
> > > uses the pseudo instead, so everything is copacetic.
> > 
> > And that expand used one pseudo for everything in the asm is bad 
> > already.
> 
> I'll contest that.  Asms aren't that special from an input-output 
> perspective and shouldn't be (makes for clearer and hence more correct 
> code).  hardregs are special, OTOH.  expand doesn't (and shouldn't) do 
> anything special for
> 
>    _2 = _1 + _1;
> 
> (i.e. it should assign the same pseudo to both inputs), from which follows 
> that it shouldn't do anything special for
> 
>   asm("" : "=r" (_2) : "r" (_1), "w" (_1))
> 
> either.  The picture changes if _1 corresponds to a local decl with an 
> associated hard reg; those don't get SSA names for a reason.  But I 
> believe you're worrying about the common case of off-the-mill SSA 
> names.

Yup.  All good points, I didn't think this through enough obviously.

The _1+_1 isn't great if that single pseudo then ends up in mem (it will
need a reload again on most archs, probably causing another spill), btw.

> Anything that would cause breakage by such behaviour of expand is to be 
> rectified by LRA/reload, not by hackery within expand.

You get worse code that way.  Reload is much too late to make optimised
code, and that isn't its task anyway: its task is to make something that
works where the passes before it couldn't manage.

Yes, reload should be able to fix up anything (well, within some limits).
That is not an excuse to generate code that we know will need such fixups
though.

I suppose check_asm_operands needs to be taught a bit more strict rules
as well about what is a valid asm.  Hrm.  A lot to think about :-)


Segher


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