On 12/06/13 03:06, Richard Biener wrote:
The issue is that we handle expansion of misaligned moves in the code
we recurse to - but that misaligned move handling can only work at
the "outermost" level of the recursion as it is supposed to see the
"real" access (alignment and mode of the memory access, not of
some base of it).
So we need a recursion that skips this part (and others - which already
works), just processing as-if in "expand the base of some memory access"
mode.
So it's really not a case of someone outside expand_expr needing
different behaviour, but a case of stopping the recursion within
expand_expr. That's a bit less concerning.
That we recurse at all when expanding memory accesses makes this
expansion path quite a twisted maze - which is why I suggested to
re-factor the whole thing to not require recursion (but that will be
a very big change, not suitable for this stage).
No doubt. In general expand_expr is a mess and has been, well, forever.
The easiest is to add a flag to indicate the "we're-expanding-the-base",
doing another expand modifier doesn't work as they are not combinable
and the passed modifier is already modified for the recursion - and that
dependent on stuff.
We could always make the modifiers a bitmask, but probably not something
we really need to do during stage3.
"Fixing" the mode of the base object isn't really fixing the fact that
the recursion shouldn't even try to generate a movmisalign mem,
it just papers over this issue by making it (hopefully) never trigger
(at least for valid code) for bases.
Ok, that answers the other question I had after looking at other parts
of this thread. Though one could argue that the modes are in fact wrong.
Jeff
