Bernd Edlinger <bernd.edlin...@hotmail.de> writes:
> Hi Eric,
>
> what you got there, looks more or less exactly like what I tried
> to fix with that patch a few months ago, but unfortunately
> we were unable to get a consensus on that approach:
>
> [PATCH] Fix asm X constraint (PR inline-asm/59155)
> https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01649.html
Does your patch also fix Eric's testcase? If so then that approach
looks safer to me FWIW. The problem with allowing arbitrary MEMs
is that it's just not clear:
(a) which other parts of the compiler (including target code) needs
to handle these arbitrary MEMs. One instance is the target-specific
code for printing an address, as Jakub says in that thread, but it
could also affect things like cost calculations, etc.
(b) should a spilled pseudo in the MEM be replaced with a MEM itself,
so that even RISC targets have to support nested MEMs? Or should
pseudo registers be reloaded? If so, into which register classes?
Should they be divided into base and index registers in the normal
way? That's difficult to do if we can't decompose the address.
Reload's always been a recurring source of problems, so the fact
that this particular case went through without an ICE doesn't mean
that arbitrary MEMs were actually safe in general.
Thanks,
Richard
