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: "+m" constraints bogus?

thanks for pointer!
> here:
> It describes the potential problem again, and I know of no changes in 
> reload which would have magically handled matching mem-only constraints.  
> I believe the problem currently only doesn't exist because the 
> gimplification mentioned by Andrew doesn't let +m come through to RTL.  So 
> it would probably be best to ensure that it stays that way, and maybe add 
> an assert instead of the warning, that we don't see matching or inout 
> constraints which don't allow registers.

Perhaps, we however still would need to warn about:
asm __volatile__ ("":"=m"(a):"0"(a));
(which correctly triggers the warning in question)
> For reference, the potential problem in reload is the following: matching 
> constraints might result in invalid operands (address not using the same 
> pseudo in our case, for instance) for which reloads are pushed.  Such 
> pushed reloads can only be satisfied by a register in an appropriate class 
> (the reload reg).  If the alternative doesn't allow any registers such 
> reload can _never_ be satisfied --> boom.  That's the old problem of 
> reload that it can't reload by using memory.

Yep, I am aware of those problems (reload dying in horrible death as
soon as something didn't ended up matching). I was somewhat confused
thinking that gimplifier gimplifies into the pair as in my testcase
above, not the "=m" "m" pair.

I guess we are safe now support them so I would just update the manual
with a simple testcase so we know gimplifier does not break and we won't
re-start emitting the warning?

> Ciao,
> Michael.

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