Ilya Leoshkevich wrote: > Am 29.10.2018 um 19:45 schrieb Ulrich Weigand <uweig...@de.ibm.com>: > > > This is true. But something else must still be going on here. Note that > > many other instruction patterns might contain constant pool addresses, > > since they are accepted e.g. by the 'b' constraint. In all of those > > cases, we shouldn't add the UNSPEC_LTREF. So just checking for the > > specific LARL instruction pattern in annotate_constant_pool_refs does > > not feel like a correct fix here. > > I have changed the patch to skip all larl_operands, regardless of which > context they appear in. Regtest is running.
Not sure that this is fully correct either. *Some* instructions, like e.g. floating-point loads, do not accept relative operands. And even for the relative loads that exist, there may be slightly different restrictions on what addresses are allowed (e.g. LGRL only accepts 8-byte aligned addresses, while LARL accepts 2-byte aligned addresses). It seems the underlying problem is that we have predicates/constraints that accept literal pool differences for two distinct reasons now: either because they can be naturally handled via relative addressing, or because they are supposed to be transformed to base-register addressing later on. We really need to distinguish the two cases in some way. Maybe it would make sense to check which alternative/constraint matched the insn, and decide based on that whether we need to rewrite to base- register addressing or not? > > In fact, before r265490, the pattern for movdi_larl could also contain a > > constant pool address, so why didn't the problem occur then? What's the > > difference whether this is part of movdi_larl or just movdi? > > The difference is usage of "X" constraint. Before, when we initially > chose movdi_larl, we could still put UNSPEC_LTREF inside it without > consequences, because during UNSPEC_LTREF lifetime only constraints are > checked. Huh, I see. That was certainly unintentional. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
