On Wed, Jan 6, 2016 at 10:18 AM, Uros Bizjak <ubiz...@gmail.com> wrote: > On Tue, Jan 5, 2016 at 10:34 PM, Richard Sandiford > <rdsandif...@googlemail.com> wrote: >> Jakub Jelinek <ja...@redhat.com> writes: >>> On Mon, Jan 04, 2016 at 03:25:48PM -0800, H.J. Lu wrote: >>>> LRA is fine. I should use >>>> >>>> (define_memory_constraint "Bm" >>>> "@internal Vector memory operand." >>>> (match_operand 0 "vector_memory_operand")) >>>> >>>> instead of >>>> >>>> (define_constraint "Bm" >>>> "@internal Vector memory operand." >>>> (match_operand 0 "vector_memory_operand")) >>> >>> I don't think so. At least the documentation says that >>> define_memory_constraint is for MEM constraints where if they are not >>> satisfied they can be made to satisfy by forcing the address into a >>> register. But that is not the case here, if a MEM is misaligned, no >>> equivalent changes to the XEXP (mem, 0) will make it aligned. >> >> Yeah. It seems like a missing feature though. Maybe >> define_memory_constraint should have two conditions, one for >> when the MEM is valid and one for when the address is? >> Guess that isn't stage 3 material though. And maybe longer-term >> we should avoid define_memory_constraint altogether and have an >> automatic way of testing whether replacing the address with a >> register is OK.
If we are going in this direction, is it possible to make define_memory_constraint more general, so it would return register class, not only default BASE_REG_CLASS? Some x86_64 instructions can use only non-REX registers (including registers in the address) when high registers (%ah, %dh, %ch and %bh) are involved. Uros.
