Ilya Leoshkevich wrote: > Am 30.10.2018 um 16:20 schrieb Ulrich Weigand <uweig...@de.ibm.com>: > > 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.
The point is, they should *not* get annotated either, since the instructions actually can handle relative accesses to the literal pool, so we don't need to use a base register. But I think that still would work; alignment shouldn't be an issue after all since literal pool contents are always naturally aligned. So we only need to recognize whether the insn alternative accepts relative operands at all, which we could do as suggested below. > > 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. Good point, that looks like it should work. For those cases where you do have to change the type attribute, we need to verify that scheduler properties do not change; this should really only be an issue with z10 (i.e. the 2097.md scheduler description). Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
