> Am 30.10.2018 um 16:20 schrieb Ulrich Weigand <uweig...@de.ibm.com>:
>
> 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).
In such instructions SYMBOL_REFs appear only inside MEMs. There is the
special case for that in annotate_constant_pool_refs (), which ensures
that UNSPEC_LTREFs are generated and recursive calls are not made. So,
the newly introduced check should have no effect on such instructions.
>
> 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?
We currently have „type“ attribute, which has the value „larl“ for most
relative addressing alternatives. In a few cases it’s „load“ / „store“,
but that looks like an omission to me: e.g. for „lhrl“ it's „larl“, but
for „lrl“ it’s „load“. We could query it from the back-end with
get_attr_type () and compare the result with TYPE_LARL.
