On Sat, Nov 02, 2024 at 08:25:45AM +0100, Jakub Jelinek wrote:
> So, I think the main question to decide is if we want to keep existing
> standard constraints work as is even in toplevel asm and add new constraints
> which will allow more stuff (like "i" which will just allow SYMBOL_REFs
> even with -fPIC, or "m" which will allow a mem with any address whose
> address could be added to e.g. constant initializers and printed),
> or whether we want to change their meaning in toplevel asm and let "i"/"s"
> there really accept SYMBOL_REFs no matter if -fPIC or not, and "m" accept
> the constant addresses of MEMs no matter what the backend chooses are
> acceptable. Because at toplevel, we really can't reload the addresses into
> registers to make the constraint be satisfied.
A third option because we are really almost out of usable generic constraint
letters, what remains are just some punctuation, would be a new constraint
modifier (like we have =+%&) which would change the meaning of selected
constraints, "i", "s", "m" at least, perhaps some others, making them work
similarly to the original, but with some changes to what exactly they accept
and what they reject, so "i"/"s"/"m" could be used in toplevel asm even
with -fpic, even if a target requires address of a memory reference in
registers etc.
Jakub
